PKIs: DNSSEC vs. X.509

Como el año pasado, una de las charlas estelares era la de Dan Kaminsky, tanto que muchos nos quedamos a todo el noticiario de Fnord en alemán (para practicar) para no perder nuestro sitio (este año he notado mucha más escasez de sitio en las charlas que en el CCC pasado, y las entradas también se han agotado el primer día -- posiblemente incluso a primera hora).

La esencia de la charla era que podíamos eliminar los passwords y los actuales certificados que usamos para seguridad (en SSL, IPSec y en algunos casos hasta en SSH), y sustituirlos por una aplicación global de DNSSEC como repositorio de autenticación y certificación.

Respecto al tema de los passwords, citaba una estadística de Verizon en la que el 60% de los problemas de seguridad estaban relacionados con ellos.

Para eliminar los problemas, citaba dos aproximaciones:

• Forzar el uso de claves más seguras, imponiendo controles estrictos de seguridad
• Aceptar que una limitación fundamental es que hay que almacenarlos en la memoria humana, cuya capacidad es bastante limitada en media, y sustituirlos por claves de alta seguridad criptográfica, que se pueden almacenar en tarjetas de memoria protegidas por claves más sencillas.
  

Tras estudiarlo Dan ha llegado a la conclusión de que lo que nos ha fallado en el intento de coseguir este último objetivo es X.509, el estándar actual de certificados que se usa en SSL, IPSec, en casi todo lo que lleve seguridad (p.e. aplicaciones firmadas) menos en SSH.

Para explicar los certificados, ha recurrido a una analogía más sencilla, que son los pasaportes: podemos aceptar el contenido de un pasaporte como cierto porque nos fiamos del esfuerzo que emplea el gobierno que emite el pasaporte en evitar las falsificaciones. Un certificado es igual, sólo que en vez de papel es electrónico, las firmas se aplican cifrando con una clave privada un extracto ("hash") del contenido y es una compañía llamada Autoridad de Certificación (CA) la que da la fiabilidad de ese documento.

Los problemas que Dan ha presentado con los certificados X.509 son:

• Más de la mitad de los certificados que se utilizan en servidores SSL en el mundo no sirven para nada, porque están firmados por los autores del contenido (como si Dan se pusiese a hacer pasaportes...)
• Una buena parte de las CA basan la fiabilidad de los certificados que emiten en usar el DNS y el Whois (que también consultan por correo electrónico que se basa en el DNS). Por tanto, la seguridad de esos certificados es tan buena o mala como el sistema de DNS (que ya sabemos de charlas anteriores que no es fiable).
• Y las CA que utilizan procedimientos más estrictos (verificando documentos de papel y registros oficiales) se ven penalizadas porque sus procedimientos son más complejos para hacer lo mismo y al final todos los navegadores aceptan todos los certificados, por lo que su producto es idéntico.
  

Comparando DNSSEC con X.509, el primero tiene ventajas respecto a:

• La capacidad de excluir a los participantes que no ofrecen servicios fiables, ya que DNS tiene raíz única, un único registro de datos para cada dominio de segundo nivel, pero a la vez competencia en los proveedores de servicios que manejan el proceso de incluir datos en el registro. Esto permite que el registro de datos puede excluir registradores que no tengan la calidad suficiente. Frente a eso, nadie controla la raíz de los certificados X.509, y la única posibilidad de determinar qué certificadores son fiables es crear una entidad de certificación privada con los criterios deseados, lo cual es costoso y lento (aunque, por ejemplo, el ejército americano ha sido capaz de hacerlo).
• La capacidad de delegar, que es intrínseca en DNS, pero que en X.509 está muy mal implementada, a pesar de que X.509 es increíblemente complejo precisamente para permitir la delegación. La opción de delegación para firmar subdominios no está implementada correctamente en casi ningún lado, y la única opción práctica para delegar hoy en día es crear autoridades de certificación delegadas, que pueden firmar cualquier certificado.
  

Y para entretener un poco más a la audiencia, todo ésto se veía salpicado de diferentes vulnerabilidades de seguridad detectadas en X.509, como:

• El uso de caracteres nulos de terminación dentro de los nombres certificados para que aparezcan como pertenecientes a otro sitio
• El uso de múltiples nombres dentro de un certificado, que crea ambigüedades respecto a lo que se ha certificado, y que permite que mientras la CA firma una cosa, el navegador piensa que ha firmado otra
• Y por último, una prediccion de un problema que aparecerá tarde o temprano, relacionado con un certificado raíz de Verisign que no expira hasta 2028, y que está firmado con una función de hash insegura, MD2 (antecesor de MD4 y MD5, los más usados hoy en día y también vulnerables). Un ataque a MD2 que permita crear un contenido con el mismo hash, permitiría hacer pasar cualquier cosa como firmada por Verisign. ¿Por qué no nos ha pasado todavía? Porque la complejidad de ese ataque a MD2 ha disminuido ya hasta ser de un orden de magnitud de 2^73 y la capacidad actual de ataque todavía es de sólo 2^63. ¿Cuánto tiempo nos quedará?
• Ambigüedades en la codificación de los OIDs de ASN.1 que podrían permitir ataques de overflow de modo que las firmas parecen ser de un CN mientras que en realidad se han obtenido firmando otro atributo.