La cadena de confianza.

Una clave pública es un número. Un número no tiene dueño, ni nombre, ni fecha de vencimiento. La criptografía garantiza que una firma fue producida con la clave privada correspondiente a cierta clave pública, pero no dice nada sobre a quién pertenece esa clave. Sin una respuesta a esa pregunta, el intercambio de Diffie y Hellman queda expuesto a un intermediario, y una firma digital no prueba quién firmó.

La respuesta que se impuso la propuso Loren Kohnfelder en su tesis de grado en el MIT, en 1978: que un tercero de confianza firme una declaración que vincule una clave pública con un nombre. La llamó certificado. Todo lo que hoy se llama infraestructura de clave pública es el desarrollo de esa idea, y este artículo la recorre desde los bytes de un certificado hasta el algoritmo que decide si una cadena es válida.

Anatomía de un certificado X.509

El formato dominante nació en 1988 como parte de la serie X.500 de la UIT, pensada para un directorio global que nunca llegó a existir. Su tercera versión agregó las extensiones, que resultaron ser lo más importante, y el RFC 5280 define el perfil que usa internet. Un certificado se describe en ASN.1, un lenguaje de definición de estructuras, y se codifica en DER, una codificación canónica: cada estructura admite exactamente una representación en bytes. Eso no es un detalle, porque la firma se calcula sobre bytes, y dos codificaciones distintas del mismo contenido darían resúmenes distintos.

Un certificado es, entonces, un documento firmado como cualquier otro. Su emisor (issuer) afirma que la clave contenida pertenece al titular (subject) durante el período de validez, con las condiciones que fijan las extensiones. Las más relevantes para la firma son estas:

Por qué una cadena y no un solo eslabón

La clave privada de una autoridad raíz es el activo más sensible del sistema: si se compromete, todo lo que cuelga de ella pierde valor. Por eso la raíz suele vivir desconectada, dentro de un módulo de seguridad de hardware, y se usa sólo en ceremonias formales, con testigos y actas, para firmar unos pocos certificados de autoridades intermedias. Son las intermedias, en línea, las que emiten los certificados de los firmantes. Si una intermedia se compromete, se la revoca sin tocar la raíz.

La raíz, en cambio, no tiene quien la firme. Su certificado es autofirmado, y su firma sólo prueba que el certificado no se alteró. La confianza en ella no es criptográfica sino una decisión: la de incluirla en un almacén de anclas de confianza. Esos almacenes los mantienen los sistemas operativos y los navegadores, con sus programas de autoridades raíz; los organismos supervisores, como las listas de confianza europeas; y los gobiernos, a través de sus infraestructuras nacionales con una raíz estatal.

Validar una ruta

El RFC 5280 dedica su sección 6 a un algoritmo preciso. Recibe una ruta de certificados, desde el que sigue al ancla hasta el del firmante, un momento de referencia y las políticas aceptables, y la procesa en orden, desde arriba hacia abajo. Para cada certificado comprueba, entre otras cosas:

• que su firma verifique con la clave pública del certificado anterior;
• que su emisor coincida con el titular del certificado anterior;
• que el momento de referencia caiga dentro de su período de validez;
• que no esté revocado en ese momento;
• que, si es intermedio, sea una autoridad (cA verdadero, uso keyCertSign) y respete la longitud de ruta y las restricciones de nombres;
• que la política del certificado esté entre las aceptables.

Antes de validar hay que construir la ruta, lo que no siempre es trivial: puede haber certificados cruzados, varias intermedias con el mismo nombre o raíces renovadas. Las implementaciones robustas prueban varias rutas candidatas. El laboratorio muestra la validación sobre una ruta de tres niveles y lo que ocurre cuando algo falla.

Revocación: el problema más difícil

Un certificado puede dejar de merecer confianza antes de vencer: la clave se perdió, el titular dejó la empresa, los datos eran falsos. El emisor debe poder anunciarlo, y el verificador debe poder enterarse.

Para la navegación web, la revocación nunca funcionó del todo: si el servicio no responde, los navegadores suelen seguir adelante, y un atacante capaz de interceptar tráfico también puede bloquear la consulta. Para la firma de documentos, el problema tiene otra forma. No importa tanto si el certificado está vigente hoy sino si lo estaba en el momento de firmar, y eso exige dos cosas: guardar la información de revocación de ese momento y un sello de tiempo de un tercero que fije el momento. Es la base de las firmas de larga duración tratadas en la primera serie de este blog.

Cuando la cadena se rompe en la práctica

En 2002 se descubrió que un navegador de uso masivo no comprobaba la extensión basicConstraints: cualquier titular de un certificado común podía emitir certificados para cualquier sitio, y el navegador los aceptaba. Fue la demostración más clara de que un validador incompleto anula toda la infraestructura.

En 2011 la autoridad certificante neerlandesa DigiNotar fue comprometida. El informe forense identificó 531 certificados fraudulentos, entre ellos uno para todos los dominios de Google, que se usó para interceptar las comunicaciones de unas 300 000 direcciones IP, en su mayoría de Irán. Los navegadores y sistemas operativos retiraron a DigiNotar de sus almacenes de confianza, el gobierno neerlandés reemplazó los certificados emitidos bajo su infraestructura y la empresa quebró en semanas. Un eslabón comprometido se lleva consigo todo lo que cuelga de él.

La respuesta estructural fue Certificate Transparency: registros públicos de solo agregado donde las autoridades deben inscribir cada certificado que emiten, de modo que cualquier emisión indebida quede a la vista. Los registros se organizan como árboles de Merkle, una aplicación directa de las funciones resumen: una sola raíz de 32 bytes compromete millones de certificados, y probar que uno está incluido requiere sólo unos pocos resúmenes intermedios.

← Todas las notas