Construir una autoridad de certificación poscuántica con los certificados Merkle Tree

Cuando escribes una dirección en un navegador, ¿cómo sabes que te estás conectando al sitio web correcto? La Web Public Key Infrastructure (Web PKI) es el ecosistema complejo y distribuido de políticas, protocolos y operadores de infraestructura que te ayuda a confiar en que no estás siendo redirigido a un sitio incorrecto o malicioso. En las últimas décadas, este ecosistema ha experimentado cambios significativos. Uno de ellos es la incorporación de la transparencia: el requisito, ya obligatorio, de que todos los certificados queden registrados en registros públicos de transparencia de certificados. Ahora se enfrenta a otro desafío: la inminente llegada de una computadora cuántica, que nos ha impulsado a migrar a la criptografía poscuántica (PQ) para 2029.

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

Tras obtener un amplio respaldo en la industria, los Certificados Merkle Tree (MTC) han surgido como el modelo a seguir. Este año, tras un exitoso despliegue experimental con Chrome, Cloudflare avanza a toda marcha 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 ofrecerá emisión de MTC, con el objetivo de ser incluida a principios de 2027 en el Quantum-resistant Root Store recién lanzado por Chrome. Como parte de nuestra misión de contribuir a construir un Internet mejor, y siguiendo la tradición de Cloudflare de ofrecer la criptografía más sólida disponible de forma gratuita, proporcionaremos la emisión estándar de MTC sin costo alguno. Contar con una CA que admita tanto la emisión de certificados clásicos como la de MTC nos permite establecer por defecto el método de autenticación más seguro disponible, que brinda una ruta de actualización PQ sencilla y de alto rendimiento para una gran parte de Internet.

El ecosistema de confianza actual

Para entender cómo los MTC están cambiando las reglas del juego, comencemos con algunos antecedentes sobre cómo funciona la confianza en la web hoy en día.

En el lado del cliente, los navegadores, en este caso, los “clientes TLS”, mantienen programas raíz que especifican un conjunto de políticas que deben seguir las CA para ser de confianza. En el lado del servidor, las CA son los guardianes de confianza: operan una infraestructura de emisión de certificados donde validan la titularidad del dominio y acreditan la vinculación entre un nombre de dominio y una clave pública que demuestra dicha titularidad.

Pero ¿cómo verificamos que las CA cumplen las normas? Entra en escena 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 opera la familia de registros CT Nimbus desde 2016 y está lanzando Raio, una nueva familia de registros CT estáticos.

Aunque el ecosistema CT hace que los certificados sean públicamente visibles, eso no significa que estén correctamente emitidos o que sea seguro utilizarlos. La monitorización ayuda en esto al comparar los registros con lo que esperaban los propietarios de dominios y notificando actividades sospechosas. Cloudflare lanzó el Certificate Transparency Monitoring en 2019 y recientemente lo puso a disposición general. También publicamos mediciones a gran escala sobre los certificados en la página de Certificate Transparency en Radar (anteriormente conocida como Merkle Town).

A medida que las organizaciones comiencen a actualizar sus servidores para usar autenticación PQ, la monitorización de la transparencia de certificados adquirirá un papel aún más importante en la detección de posibles degradaciones poscuánticas. Los propietarios de dominios que hayan migrado a la autenticación poscuántica deben monitorizar los registros CT en busca de certificados heredados emitidos de forma inesperada, para evitar que los clientes recurran a una ruta de degradación maliciosa.

Parte del problema con este sistema actual es que la transparencia fue un complemento posterior, lo que le genera problemas de escalado. Los certificados se registran frecuentemente varias veces, en diferentes formatos y en múltiples registros, lo que obliga a los monitores a descargar y procesar cada registro para no perder ninguna emisión. Esto puede ser costoso, dificultando la aparición de un conjunto diverso de operadores de registros a escala de Internet. Según nuestras estimaciones, las firmas PQ harán que la cantidad de datos que los registros CT deben almacenar se multiplique por 40. Este desafío de escalado, y el consecuente desajuste de incentivos, está en el centro del problema de escalado poscuántico.

El problema de escalado poscuántico

Hemos escrito extensamente sobre los desafíos del escalado de la criptografía poscuántica, pero en resumen: para admitir la autenticación de servidores a escala de Internet, la Web PKI debe autenticar aproximadamente mil millones de servidores TLS sin precargar la clave pública de cada servidor en cada cliente. Tradicionalmente, las CA han abordado este problema usando cadenas de certificados como mecanismo de distribución de confianza. Sin embargo, con el tiempo, incorporaciones como las verificaciones 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 TLS handshake típico. Las firmas PQ son aproximadamente 40 veces más grandes que las clásicas, lo que genera sobrecargas mayores que serían costosas de gestionar a escala para clientes, CA, registros y monitores.

Aquí entran los certificados Merkle Tree (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 certificados en un árbol de Merkle de solo adición, lo que permite a una CA firmar la raíz de ese árbol en lugar de muchos certificados individuales. Esto permite a los navegadores u otros clientes verificar un certificado usando una prueba de inclusión compacta, es decir, una secuencia de hashes criptográficos, para comparar con la raíz  de árbol firmada, en lugar de validar cada certificado individualmente. Una idea clave detrás de los MTC es «no registrar lo que se emite, emitir a través del registro». Al vincular la emisión y el registro, la transparencia se convierte en un requisito operativo, no en un complemento.

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

Estamos ampliando nuestra capacidad para emitir MTC como parte integral de la creación de una CA de Cloudflare. Esto implica seguir los nuevos requisitos de los programas raíz PQ y desarrollar una pila de software de emisión y duplicación al mismo tiempo que construimos las instalaciones, las operaciones y las funciones de cumplimiento de la CA tradicional, ¡todo un desafío!

La ventaja es que podemos priorizar desde el primer día los requisitos y la arquitectura de esta nueva PKI poscuántica, y construir nuestra configuración de una manera que refleje los valores y la red global de Cloudflare, con el objetivo de ser lo más transparentes posible en este nuevo recorrido.

Veamos la arquitectura actualizada para los MTC:

Si la comparas con el ecosistema de CA tradicional, notarás que las responsabilidades de una CA se mantienen en gran medida igual: validar el control de un dominio, vincularlo a una clave pública y emitir certificados. La diferencia principal es que en el ecosistema MTC, en lugar de firmar 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 demuestra que el certificado está efectivamente en el árbol sirve como ancla de confianza. Las CA también operarán firmantes espejo que almacenan una copia de los registros de emisión, verificando su consistencia de solo adición y garantizando la transparencia y disponibilidad de estos registros para el ecosistema en general.

Emisión de MTC

Los MTC existen en dos formas, ambas codificables en el formato de certificado X.509 que el software cliente reconoce hoy, simplemente con un algoritmo de firma “especial”. En la forma autónoma, el valor de firma del certificado contiene una raíz de árbol firmada de un registro de emisión y una prueba de inclusión (una secuencia de hashes) que demuestra que el certificado está contenido en ese registro. Si los clientes pueden obtener las raíces de árbol firmadas fuera de banda (por ejemplo, a través de un mecanismo de actualización del navegador), el certificado puede ofrecerse en cambio en la forma landmark-relativa, donde el valor de firma consiste en la prueba de inclusión ligera sin firmas poscuánticas pesadas.

Para simplificar, veamos un ejemplo de emisión de certificados autónomos. Cuando un sitio web quiere un certificado para su dominio, puede solicitarlo a una CA a través del protocolo Automatic Certificate Management Environment (ACME), que gestiona las solicitudes de certificados, la validación del control de dominio y los flujos de trabajo de emisión. La infraestructura ACME de Cloudflare será una alternativa de Boulder, el software ACME ampliamente desplegado y probado que impulsa a Let's Encrypt. Let's Encrypt está desarrollando activamente la compatibilidad con MTC en Boulder, y planeamos mantener nuestra propia alternativa que incorpore estos cambios del repositorio principal junto con modificaciones específicas de Cloudflare, contribuyendo de vuelta al repositorio principal siempre que sea posible.

Cuando la CA de MTC recibe una solicitud de emisión de certificado, el servidor ACME de la CA verifica que el servidor controla efectivamente el dominio. Si estas verificaciones se superan, la CA serializa esos datos y los añade a un registro de solo adición.

Tras añadir la entrada MTC a su registro de emisión, la CA calcula el estado actualizado del registro y firma un punto de control sobre ese estado. Este punto de control certifica que la CA emitió cada entrada incluida en el árbol de Merkle del registro hasta ese momento.

La CA envía entonces su estado de registro actualizado y el nuevo punto de control a un firmante de confianza, que almacena de forma duradera una copia del registro de emisión de la CA y verifica que cada nuevo estado sea de solo adición, coherente con el árbol anterior y correctamente formado. Esta firma adicional da a los clientes y monitores la certeza de que otra parte de confianza ha observado el mismo estado del registro y ha verificado que la CA no presenta vistas diferentes de la emisión a distintas partes del ecosistema. También garantiza que los certificados emitidos estén disponibles para la monitorización aunque el registro de emisión de la CA no esté disponible.

La política borrador del Quantum-resistant Root Program de Chrome exige al menos dos firmas: una de un Cofirmante Espejo reconocido por Chrome operado por una organización independiente, y otra de la propia CA de MTC emisora. Por ello, operaremos mirrors para otras CA piloto y exigiremos al menos una firma independiente en nuestros propios certificados emitidos.

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

Por último, tras recibir correctamente una firma de un firmante espejo, la CA construye un MTC con las firmas, la clave pública del servidor y una prueba de inclusión. Luego envía ese MTC al servidor, que puede usarlo para TLS a partir de entonces.

Distribución eficiente de firmas PQ: optimización de los puntos de referencia

Aunque los certificados autónomos son funcionales, siguen enviando grandes firmas PQ a través del protocolo de enlace TLS, lo que limita su eficiencia. Las verdaderas mejoras de rendimiento del diseño MTC provienen de los certificados de de los puntos de referencia relativos.

En lugar de enviar firmas en cada certificado, las CA pueden designar una secuencia de subárboles que cubran todos los certificados activos en el registro como los puntos de referencia, y distribuir estos 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 ante el servidor ocurre cuando el navegador verifica que los datos de certificado del servidor, incluido su nombre de dominio y clave pública, aparecen en un subárbol de confianza del registro de la CA. Si la prueba de inclusión conecta ese certificado con un punto de referencia firmado, y la clave pública luego demuestra la posesión durante el protocolo de enlace TLS, el cliente sabe que está hablando con el servidor correcto.

Al transmitir periódicamente estas firmas y metadatos del árbol a los clientes TLS fuera de banda, un pequeño conjunto de firmas por lotes de MTC puede cubrir eficientemente 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 autónomos: los clientes pueden estar recién instalados, sin conexión o no tener la actualización de los puntos de referencia relevantes. Por eso es importante que los servidores conserven un certificado autónomo como alternativa.

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

Este año realizamos un experimento con Chrome para probar la viabilidad de los MTC entre un cliente y un servidor. Operamos una «CA bootstrap» (una CA ficticia 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 sirvió al 50 % de los usuarios de Chrome Beta 146. A lo largo del experimento servimos con éxito miles de millones de MTC.

Para TLS, observamos que el caso habitual es bastante eficiente: con un certificado landmark-relativo, el handshake solo necesita 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 autónomo en los casos en que no pudimos negociar un certificado landmark-relativo con el cliente. En el lado de CT, los MTC también cambian las propiedades de escalado de la transparencia: el registro solo necesita almacenar hashes de claves públicas; no hay firmas por entrada y la firma sobre la cabeza 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 de todos los certificados que emite, y los consumidores del registro solo necesitan recuperar una única copia de cada certificado.

El resultado: ¡los MTC realmente funcionan! En la mediana, usar un MTC es un 9 % más rápido con MTC de puntos de referenc frente a una cadena de firmas clásica (hay que reconocer que la mayor parte de esta mejora se debe a la eliminación de intermediarios). Y dado que probamos los MTC con firmas clásicas, esperamos una mejora aún mayor con firmas poscuánticas. Satisfechos con estos resultados y con el nivel de colaboración intersectorial en los MTC en el PLANTS WG del IETF, comenzamos a cerrar el experimento el mes pasado (agosto de 2026).

El futuro para los MTC

Nos complace que nuestro experimento con Chrome haya demostrado que los MTC pueden funcionar en la práctica, y estamos especialmente emocionados de poder emitir certificados como una CA real.

Sin embargo, aún hay preguntas más amplias que solo podemos responder llevando a cabo este gran experimento con todo el ecosistema PKI. ¿Pueden los monitores independientes consumir y verificar los registros de emisión de MTC a volumen de producción? ¿Surgirán múltiples CA y firmantes para que el sistema tenga la diversidad necesaria para ser un sistema sólido? ¿Cómo deben equilibrar los navegadores las ventajas de rendimiento de los MTC de puntos de referencia compactos con las rutas alternativas necesarias para clientes sin puntos de referencia actualizados? Los MTC han emergido como el diseño de referencia para la autenticación poscuántica, pero demostrarlo a escala de producción de Internet requerirá la participación de un conjunto diverso de programas raíz, fabricantes de navegadores, CA, firmas espejo, monitores y la comunidad en general.

Vemos la oportunidad de participar en esta próxima fase de la Web PKI como un honor, y tomamos en serio la responsabilidad de operar una infraestructura de CA. Las CA ocupan una posición privilegiada en el ecosistema de confianza: navegadores, propietarios de dominios y usuarios cotidianos confían en ellas para validar identidades correctamente, proteger claves de firma, cumplir las políticas y operar de forma fiable. Antes de que la CA de Cloudflare pueda ser considerada de confianza por los navegadores para emitir MTC, tendremos que solicitar la inclusión en el Quantum Resistant Root Store de Chrome y pasar por un riguroso proceso de evaluación. Recibimos ese escrutinio de buen grado y esperamos mantenernos al mismo nivel de exigencia que cualquier otra CA en la que se confía para ayudar a proteger Internet. Esperamos que otras CA surjan para apoyar la adopción de los MTC, y estamos ansiosos por colaborar con cualquier navegador que quiera implementarlos.