Siete llaves y un destino: la seguridad de Internet y los DNS

Desde hace unos cuatro años, varias personas se reúnen cada tres meses en las instalaciones de la ICANN en Estados Unidos para llevar a cabo una ceremonia realmente curiosa. Hasta ahora esto había pasado por debajo del radar, pero James Ball, periodista de The Guardian, pudo estar en una de esas ceremonias contando todo desde dentro.

La ceremonia es una versión más elaborada, compleja y segura de lo que hacemos con menor frecuencia de la que deberíamos: cambiar nuestras contraseñas. Esas siete llaves controlan la seguridad del sistema DNSSEC , uno de los puntos troncales para la seguridad en Internet – aunque no está todavía extendido por toda la red -.

Tras pasar varios controles de seguridad, incluyendo un reconocimiento de retina que no acaba de funcionar del todo bien, siete representantes con amplia experiencia en seguridad se reúnen con varios testigos y otros oficiales para dar comienzo a la ceremonia. Cada representante tiene una llave metálica que abre una caja fuerte. En esas cajas hay tarjetas inteligentes (smartcards) guardadas en cajas con indicadores de manipulación.

Esas tarjetas activan el HSM, el encargado de firmar las claves.

Una vez recuperadas las tarjetas y después de verificar que no se ha accedido a ellas desde la última vez que se guardaron, se activa con ellas un HSM (Hardware Security Module o módulo de seguridad hardware). El HSM se conecta a un ordenador y, después de seguir pasos detallados al milímetro – incluyendo como configurar una impresora -, se ejecuta el procedimiento de firma y se crea una SKR (Signed Key Response), que contiene las nuevas claves que habrá que distribuir por Internet para asegurar los sistemas DNS. La SKR se guarda en una memoria USB, y sus contenidos serán transmitidos por un operador de ICANN a VeriSign a través de una conexión segura.

Después de que la firma se complete, se vuelven a aplicar cuidadosos procedimientos para guardar de nuevo las tarjetas inteligentes y dejar todo tal y como estaba, listo para la siguiente ceremonia de firmado.

Todos los detalles del evento están en el muy recomendable relato de The Guardian, en inglés. Pero, ¿en qué consiste realmente esa ceremonia? ¿Qué quiere decir que esas llaves tienen el destino de la seguridad de los DNS en sus manos? Os invitamos a profundizar algo más en el tema con Genbeta.

Fallos de seguridad en DNS y su respuesta: DNSSEC

Muchos ya sabréis de qué estamos hablando con DNS . Por si acaso, hagamos un repaso rápido. Como os podéis imaginar, los ordenadores y los humanos no se llevan muy bien: a los primeros les gustan los números y a los segundos nos gustan las cadenas de texto. Eso genera ciertas discrepancias a la hora de, por ejemplo, navegar a páginas web. El ordenador identifica los servidores con una dirección IP, como pueda ser 199.16.156.230. Esto le da información más que suficiente para enrutar las peticiones a través de la red y mostrarte la página web de, por ejemplo, Genbeta.

Si nosotros tuviésemos que acordarnos de esas direcciones cada vez que queremos visitar una página web andaríamos servidos. Para eso está el sistema DNS: traducir cadenas fáciles de recordar como genbeta.com a las respectivas direcciones IP que interpreta el ordenador, promoviendo así la paz, el amor y el entendimiento entre máquinas y humanos. Como Her, pero en pequeño y discreto.

Y como buen sistema que pretende llevar la paz al mundo, también es un poco ingenuo. Tenemos que tener en cuenta el contexto: DNS se creó en los inicios de Internet, cuando poca gente tenía acceso a él y no había hackers malvados (ya sabéis, los del antifaz, fusil y cebolla a la espalda). Si un servidor DNS te decía “genbeta.com tiene la dirección 87.12.3.12” te fiabas.

DNS tiene un importante fallo: no hay forma de verificar que la respuesta es legítima y no ha sido modificada

Pero se veía que eso tenía fallos. Ya en 1990 se empezaron a difundir avisos sobre los problemas de seguridad del protocolo. Por ejemplo, si a un servidor le preguntaban la IP para el dominio “pepe.com”, podía responder “pepe.com tiene la IP 1.2.3.4. Por cierto, tubanco.com tiene la dirección 7.8.9.0, apúntate eso también”. Y tu ordenador se lo creía. También era posible interceptar las comunicaciones entre tu ordenador y los servidores DNS, modificando las repuestas a las IPs que le convenga al atacante. Es decir, se podía realizar DNS Spoofing y engañar a los navegadores para que accedieran no al servidor real de tu banco, sino a uno falso que obtendría tu usuario y contraseña.

En 1999 se plantea el estándar DNSSEC . Introducía el concepto de firmar digitalmente los registros de DNS, para asegurarte así que no habían sido modificados por el camino.

La idea era buena, pero contaba con un pequeño fallo de diseño. Si se actualizaba la clave de un servidor, se tenían que regenerar cada una de las firmas de los registros dependientes. Por ejemplo, si cambiaba la clave de firma del servidor raíz de los dominios .com, habría que volver a firmar todos y cada uno de los dominios. Imaginaos qué bien se lo pasaría el servidor raíz encontrándose con más de 100 millones de dominios que firmar, recibidos de varios servidores DNS a lo largo y ancho del globo y teniendo que intercambiar una cantidad de datos más que considerable para llevar a cabo la firma de cada dominio. Una fieshta .

La IETF (Internet Engineering Task Force) crea un estándar modificado, DNSSEC-bis, que además de proporcionar seguridad consigue no ser un sistema para la autodestrucción por sobrecarga de servidores DNS . El cambio consiste en que cada servidor tiene su propia clave, que está firmada por el servidor anterior en la jerarquía. Por ejemplo, la clave de los servidores DNS de GoDaddy para dominios .com estaría firmada por VeriSign (los gestores de todos los dominios .com), y la clave de firmado de VeriSign estaría firmada por…

Efectivamente, lo habéis adivinado. La ICANN. Y eso nos lleva a nuestros queridos señores expertos y criptógrafos que tienen una llave que abre una caja que tiene otra caja que tiene una tarjeta que activa un módulo que tiene una clave que firma cosas. Enhorabuena a los que hayáis leído la última frase de una tirada, y sigamos ahora con más detalles.

ZSK, KSK, KSR, SRK

Línea de tiempo para las claves de DNSSEC.

Los informáticos somos muy dados a las siglas, ya lo sabéis. En concreto, las del título explican, en orden, el proceso que se lleva a cabo en la ceremonia de la ICANN .

Empezamos con la ZSK: Zone Signing Key (clave de firmado de zona). Esta clave, RSA de 1024 bits, pertenece a VeriSign, una empresa estadounidense dedicada a la seguridad e infraestructura de redes. Entre otras cosas, está encargada de mantener el fichero raíz de zonas. Se trata de un registro que indica qué servidores DNS corresponden a cada TLD (los TLD o top level domain son las terminaciones de los dominios: .com, .net, .es…). Es, por lo tanto, la raíz de todo el sistema DNS (de ahí su nombre). En DNSSEC, esos registros se firman con la ZSK, lo que certifica su autenticidad.

Ahora bien, alguien tiene que certificar que efectivamente esa ZSK es legítima y pertenece a VeriSign. Eso lo hace la ICANN con la KSK o Key Signing Key (clave de firmado maestra), clave RSA de 2048 bits. La parte pública está disponible en su sitio web para que cualquiera pueda consultarla y verificar la cadena de firmas. La parte privada, la que se utiliza para firmar, permanece guardada en los HSM que comentábamos antes antes.

Hay que renovar las claves de cifrado cada poco tiempo para evitar que se reutilizen registros antiguos inválidos

Hay un pequeño problema con las firmas de las ZSK, que viene bien explicado en la página de DNSCurve. Imaginaos que vuestro banco cambia de proveedor de hosting, y la IP de los servidores cambia. Hasta ahora todo normal. Pero, ¿qué pasa si alguien consigue poner sus servidores en la IP antigua del banco? Podría haberse guardado las firmas de esos registros, que seguirían siendo válidas, y así redirigir a usuarios al sitio web falso para robar claves y hacer demás cosas malvadas.

Hay que fijar tiempos de validez para las claves y minimizar los riesgos de que eso ocurra. Actualmente, el tiempo de validez son 15 días, y recordemos que cada una de esas claves ZSK tiene que ir firmada por la KSK. Para evitar sobrecargas, VeriSign hace las peticiones de firmado en tandas de 9 claves.

Esas peticiones son las KSR o Key Signature Request (petición de firmado de claves). En la ceremonia de firmado de la ICANN se comprueba primero la integridad de la KSR, comprobando que el hash o huella digital del KSR recibido coincide con el que calculó VeriSign al generar la petición. Después, se verifica que las ZSK sean las mismas que se generaron en la anterior ceremonia.

Los HSM son los módulos hardware que contienen la clave de firma, KSK, y los que firmarán cada una de las ZSK. El resultado se encapsula en una SKR o Signed Key Response (respuesta de claves firmadas), que se enviará a VeriSign. Una vez obtenida la autorización de la NTIA (la agencia de administración de telecomunicaciones estadounidense), VeriSign usará las nuevas claves para firmar los registros del archivo raíz de zonas. Tres meses después, se volverá a repetir la ceremonia para regenerar las ZSK.

Esquema de las instalaciones para la ceremonia.

Con todo este procedimiento se trata de establecer una raíz de confianza para todo el sistema DNSSEC , una entidad que todo el mundo tome por confiable por defecto. Eso explica toda la seguridad y parafernalia alrededor de la ceremonia: si alguien ajeno a la ICANN tuviese la clave maestra, podría modificar los registros DNS sin alertar (al menos no inmediatamente) de que han sido modificados y están redirigiendo a servidores potencialmente peligrosos.

La ICANN y los expertos responsables de las llaves que dan acceso a las claves mantienen que el sistema es seguro y que es prácticamente improbable que alguien se haga con la clave privada. Es cierto que no es algo que el mundo de la seguridad cuestione, aunque sí es más polémico el control de Estados Unidos en todo el proceso. VeriSign es una empresa privada estadounidense, la ICANN tiene la misma procedencia y las ceremonias se realizan igualmente en Estados Unidos. En algunos países esto produce desconfianza, más aún tras las filtraciones de la NSA , y se propone que el control pase a manos de organizaciones internacionales como Naciones Unidas.

Más información | The Guardian

The post Siete llaves y un destino: la seguridad de Internet y los DNS appeared first on i-RME.es.

from i-RME.es http://ift.tt/1f07Rl5

Este articulo pertenece a sus respectivos autores y se distribuye bajo licencia Creative Commons Reconocimiento 3.0. Algunos articulos pertenecen a BlogdeBlogs quien es el responsable de definir la licencia aplicable.