Merkle Tree Certificates: la tercera iteración de la PKI web

Durante los últimos tres meses he estado explorando la criptografía poscuántica, su impacto en Internet y cómo está transformando el estado de la criptografía y la seguridad de red. En esta publicación, la séptima y última de la serie, analizo cómo se está rediseñando la autenticación web mediante los Merkle Tree Certificates (MTC).

Al principio solo existía la PKI de Internet, que abarcaba toda la autenticación pública entre software cliente y servidor de todo tipo. Por si no estás familiarizado con el término, PKI significa Public Key Infrastructure (infraestructura de clave pública). A pesar de la palabra «pública» en su nombre, las PKI no tienen por qué ser públicas ni estar abiertas a todo el mundo, pero la PKI de Internet sí lo es.

La historia de cómo surgió la PKI de Internet es fascinante, aunque en esencia se reduce a un ingeniero de los primeros tiempos de Netscape, Kipp Hickman, que tardó tres meses en resolverlo todo. Por cierto, ese tiempo incluyó el trabajo para crear la primera versión de Secure Sockets Layer (SSL) y la PKI de Internet (basada en X.509, que ya existía). Al parecer, esta última parte (la autenticación) fue en gran medida algo secundario. Con el trabajo de Kipp, Netscape dio paso a la era de las comunicaciones seguras, y el mundo lo siguió.

Este primer sistema funcionó durante una década aproximadamente, pero con el tiempo las grietas se hicieron demasiado grandes para ignorarlas. El CA/Browser Forum, un grupo del sector formado por autoridades de certificación (CA) y navegadores, se creó en 2005 y, en 2007, publicó su primer documento para empezar a formalizar la emisión de certificados. Ese trabajo continúa desde entonces.

Paralelamente, los fabricantes de navegadores, con Google a la cabeza, empezaron a ejercer un control cada vez mayor sobre lo que se considera seguro. Los navegadores comenzaron a utilizar los certificados de una forma ligeramente distinta, lo que dio lugar a la PKI web. Al principio, las diferencias eran pequeñas. Una nueva tecnología llamada Certificate Transparency (CT) se volvió obligatoria en 2018 y cambió radicalmente la PKI web. Esta incorporación marcó la segunda iteración de la PKI web, la que tenemos hoy. La reciente eliminación de la autenticación de cliente fue el último cambio que consolidó las diferencias.

Enseguida entraré en detalle, pero la decisión de rediseñar la PKI web se reduce a estos tres problemas clave:

1. El ecosistema CT actual ya es frágil de por sí
2. La reducción prevista de la vigencia de los certificados muy probablemente lo romperá
3. Las firmas poscuánticas, más grandes, acabarán de enterrarlo

En pocas palabras, la migración poscuántica es el detonante que nos ayudará a justificar el trabajo necesario para que todo funcione con mucha más fluidez. Habrá mucho trabajo nuevo, pero no vamos a tirar por la borda todo lo que hemos aprendido hasta ahora.

La función de Certificate Transparency (CT) es garantizar una visibilidad total sobre la emisión de certificados en todo el mundo. Para ello, los certificados se registran en logs de CT, protegidos mediante criptografía. Como resultado, los logs de CT se han convertido en una pieza crítica de la autenticación web.

Como todos los grandes navegadores y muchos sistemas operativos exigen ya CT, no se pueden emitir certificados si no se registran. Esto significa que necesitamos logs de CT de alta disponibilidad capaces de soportar los picos de emisión mundiales, y algo más. Aunque hasta ahora no ha habido caídas importantes, si sigues las listas de correo adecuadas sabrás que ha habido dificultades. El sector está preocupado.

Las decisiones ya tomadas empeorarán la situación. Para 2029, la vigencia máxima permitida de los certificados se reducirá a solo 47 días, frente a un año, un límite que de por sí es bastante reciente. Esto significa que pasaremos de una emisión anual a una mensual, es decir, 12 veces más.

También es posible que se introduzcan nuevas reducciones de la vigencia. La política inicial de Apple sobre autenticación poscuántica, por ejemplo, solo permite 7 días. No está claro si esto solo se exige durante la fase de prueba o si la intención es mantenerlo. Si se mantiene, supondría multiplicar por 4 la emisión mensual, que hasta ahora era la más corta. En total, unas 50 veces la carga actual del ecosistema CT en número de emisiones.

El aumento del número de certificados es solo una parte del problema. Como quizá recuerdes de mi publicación anterior, las firmas y los algoritmos de clave pública poscuánticos son mucho más grandes, lo que por sí solo podría multiplicar entre 10 y 20 veces el tamaño de los certificados (y de los logs de CT). Multiplica ambas cosas y entenderás por qué hay preocupación.

La tercera iteración, en forma de Merkle Tree Certificates (MTC), está diseñada como solución.

La diferencia más importante de los MTC es que unen X.509 y CT. En el modelo actual, CT es un complemento. Registrar los certificados en CT es un paso independiente. Las organizaciones que emiten los certificados no son las mismas que los registran en CT. Esto supone una debilidad estructural y provoca un desajuste de incentivos.

Con los MTC, cada CA gestiona una instancia de un log de CT (de nueva generación) y escribe en él sus certificados. La frase que oirás a menudo es que las CA «emitirán mediante registro». Donde antes había dos pasos, ahora solo hay uno. Con este cambio, todas las CA tienen que participar también en el ecosistema CT; no hay otra forma.

Como los MTC se emiten mediante registro, los precertificados, que actualmente exige CT, dejan de ser necesarios. A partir de ahora solo se registrará un objeto. Este cambio reduce la complejidad operativa y puede reducir hasta a la mitad el tamaño de los logs de CT. (Las mayores CA actuales envían a CT tanto precertificados como certificados.)

Un aspecto importante de CT es que la emisión de certificados la atestiguan (witnessing) y replican terceros. No confiamos en que una sola organización haga lo correcto. En CT v1, los certificados se registran de forma individual. Un log de CT contiene una variedad de certificados emitidos por distintas CA. Además, cualquiera puede enviar un certificado para que se registre en el log.

Con los MTC, la atestación y la replicación se producen a nivel de log. Las CA emiten certificados registrándolos en sus propios logs. Estos se firman y después se atestiguan y replican por lotes. Un log espejo es idéntico al log original. Esto tiene grandes ventajas:

• Las operaciones por lotes son más ágiles y eficientes.
• Los terceros ya no pueden enviar certificados arbitrarios, lo que reduce la duplicación de trabajo (certificados registrados innecesariamente) y evita sobrecargar los logs de CT.
• Los monitores ya no tienen que vigilar todos los logs de CT del mundo para obtener todos los certificados; solo necesitan supervisar una instancia, o incluso repartir la carga entre varias instancias del mismo log.

Como todos los emisores de MTC son también operadores de logs MTC, es probable que se asocien con otras CA con volúmenes de emisión similares para replicar mutuamente sus certificados.

En los inicios de CT, cada log tenía una sola instancia, y eso funcionó bien durante un tiempo. Los primeros logs eran anuales porque, una vez caducados todos los certificados de un log, ya no era necesario conservarlos. Sin embargo, los logs anuales acabaron siendo demasiado grandes, así que se añadieron fragmentos (shards) más pequeños (por ejemplo, de 6 meses).

La creación y gestión de los fragmentos de los logs de CT genera una carga operativa continua y considerable. Los operadores tienen que dedicar mucho tiempo a crear y gestionar los fragmentos, y después a eliminarlos. Luego, los nuevos fragmentos deben supervisarse y validarse en colaboración con los principales consumidores (los fabricantes de navegadores). Por último, su información tiene que propagarse hasta los usuarios finales.

Los MTC admiten la poda de logs. Gracias a cómo se construyen internamente los logs (y a cómo está diseñada la validación criptográfica), es posible eliminar por completo las partes caducadas. Será un cambio muy bien recibido por quienes tienen que asegurarse de que el ecosistema funciona, y funciona bien.

En el diseño actual de CT, cada entrada contiene la clave pública asociada y la firma de la CA. Hoy son pequeñas, pero su tamaño se disparará con la PQC. Con los MTC, las claves públicas se omiten y se sustituyen por una combinación de identificador de algoritmo y hash. Las firmas de la CA también se excluyen (porque los logs MTC se firman por lotes).

Este cambio reduce considerablemente el tamaño de los logs de CT, sobre todo teniendo en cuenta que a partir de ahora no habrá precertificados y que no será posible registrar certificados arbitrarios.

Ya hemos visto que los MTC facilitarán mucho la gestión de los aspectos de transparencia de la autenticación web. Sin embargo, la mayoría de los análisis se centran en la reducción del tamaño de los handshakes TLS. Para entender este problema, te recomiendo leer mi publicación anterior sobre el tamaño de las firmas poscuánticas y su impacto en el rendimiento de la red. Quizá también te interese esta publicación de seguimiento, centrada en las pruebas que respaldan las afirmaciones sobre el rendimiento.

Los Merkle Tree Certificates existen en dos formas. Una se denomina independiente (standalone) y equivale, a grandes rasgos, a los certificados tal como los conocemos hoy (X.509 + CT).

En los certificados independientes, las firmas se sustituyen por una prueba de inclusión (inclusion proof), una estructura basada en hash que cumple una función similar. Lo fundamental es que, aunque las pruebas de inclusión son más grandes que las firmas RSA y EC actuales (unos 384 bytes), son mucho más pequeñas que las firmas poscuánticas. Como resultado, cada MTC independiente es mucho más pequeño.

Hay otro cambio. Los MTC los emiten directamente CA de confianza, por lo que ya no necesitamos certificados intermedios en el handshake TLS, lo que reduce aún más el tamaño.

Los certificados independientes son sencillos desde el punto de vista conceptual, pero no bastan para reducir el tamaño de los handshakes TLS poscuánticos hasta los niveles actuales. Si queremos mejorar, tenemos que ir más allá y aumentar considerablemente la complejidad. Esto llega con la segunda forma que pueden adoptar los MTC, los llamados Landmark-Relative Certificates.

Los certificados independientes son más pequeños, pero siguen teniendo que incluir firmas, que en el mundo poscuántico son muy grandes. Los Landmark-Relative Certificates (LRC) son mucho más pequeños porque su único mecanismo de autenticación es una prueba de inclusión; no contienen firmas. La prueba de inclusión de los LRC no es la misma que la de los certificados independientes, por lo que es algo más grande, pero no demasiado (unos 736 bytes, aproximadamente el doble).

Pero hay una pega. Para funcionar, los LRC necesitan pruebas de inclusión emitidas con respecto a landmarks (puntos de referencia), que son grupos (subárboles) de certificados emitidos. Para que los agentes de usuario puedan autenticar estas pruebas de inclusión, deben disponer previamente de información sobre los landmarks correspondientes, lo que significa que tienen que obtener continuamente algo de algún sitio para cada CA en la que confían. Ay.

Si eres usuario final, nada de esto te va a importar. Admitir los LRC conlleva mucha complejidad adicional, pero la asumirán y la «pagarán» los desarrolladores de agentes de usuario y los operadores de servidores. En el caso de estos últimos, la esperanza es que la mayor parte la gestione el software de automatización, mediante ACME.

Los Landmark-Relative Certificates son una optimización. Cuando todo sale bien, los handshakes TLS son cortos y rápidos. Si no, los agentes de usuario recurren a los certificados independientes, que son más lentos, pero no se rompe nada.

En el lado positivo, según Cloudflare, los LRC ofrecen un rendimiento un 9 % mejor que las cadenas de certificados clásicas que usamos hoy. La mejora sería mucho mayor frente a los certificados independientes, y considerablemente mayor frente a hipotéticas cadenas de certificados X.509 + ML-DSA que no queremos usar en la Internet pública.

Dicho esto, en las redes privadas, que son entornos controlados y a menudo tienen una conectividad mucho más rápida, las diferencias de rendimiento quizá no sean tan pronunciadas. Una simple evolución de X.509 que incorpore ML-DSA podría funcionar perfectamente.

Después de todo esto, intentemos averiguar cuántos certificados podríamos necesitar para obtener el máximo rendimiento. Hoy en día, la configuración más robusta consiste en tener dos certificados: uno EC, más rápido, y uno RSA, ampliamente compatible.

Para neutralizar la amenaza de los ordenadores cuánticos criptográficamente relevantes, tendremos que pasar a la autenticación poscuántica mediante MTC. Como mínimo, esto implica admitir certificados independientes. Así que necesitaremos al menos tres, para dar servicio tanto a los agentes de usuario modernos como a los más rezagados.

Por desgracia, con un solo certificado independiente, el rendimiento de nuestros handshakes TLS será peor que el actual. Quizá eso sea aceptable, pero si queremos solucionarlo, también tendremos que admitir los Landmark-Relative Certificates. Y de esos necesitaremos dos, no solo uno.

Por tanto, necesitaremos al menos cinco certificados por servicio.

Hay un par de razones por las que existen certificados independientes y Landmark-Relative Certificates. Los independientes se pueden crear inmediatamente al emitirse. En cambio, los LRC se generan por lotes, por lo que no están disponibles de inmediato. Tendrás que esperar un tiempo (por ejemplo, 1 hora) antes de poder obtener uno que corresponda a tu certificado independiente.

Y eso no es todo. Como ya vimos, para autenticar un LRC, los agentes de usuario deben obtener primero información de la CA. (De forma indirecta, a través de un servicio de actualización del agente de usuario.) Los agentes de usuario no buscarán nuevos landmarks de forma continua, sino solo periódicamente. Además, pueden estar sin conexión durante un tiempo. Por ello, normalmente los agentes de usuario no tendrán los landmarks más recientes.

En resumen: 1) necesitas un certificado independiente para todos, 2) un Landmark-Relative Certificate más antiguo para la mayoría de los agentes de usuario y 3) un certificado landmark más reciente que acabará convirtiéndose en tu certificado principal a medida que los agentes de usuario se pongan al día.

Imagina tener que hacer todo esto a mano. No es de extrañar que necesitemos ACME… la automatización es la única forma de que esto funcione. Y aun así, diagnosticar problemas de autenticación y rendimiento será más difícil. La supervisión continua para detectar los problemas a tiempo será necesaria para un abanico mucho más amplio de organizaciones.