jueves, 21 de mayo de 2015

Logjam, el hacedor de llaves en el reino de las cerraduras cobardes

Al pilar que sostiene la privacidad de nuestras comunicaciones le ha salido una nueva grieta que vuelve a amenazar la integridad y el secreto que percibimos como seguros. Un golpe a la criptografía bautizado Logjam que demuestra (otra vez) la fragilidad de un sistema vital para la confianza. Veamos en qué consiste Logjam.

https://weakdh.org/
En toda comunicación segura existe un momento crítico al principio de la conexión. Ambas partes han de ponerse de acuerdo en la clave que van a utilizar para el uso de cifrado simétrico. El problema no era sencillo, más teniendo en cuenta que el medio por el que iban a viajar los mensajes para coordinar la elección de dicha clave era y es hostil: Internet.

A mediados de los años setenta, aparte del éxito de las patillas de hacha y los pantalones de campana, unos científicos propusieron un método de intercambio de claves, aunque sería más apropiado decir "método de acuerdo de clave compartida", para solucionar el problema de intercambio inicial de mensajes entre dos partes a través de un canal inseguro. El método se conoce popularmente como Diffie-Hellman (si, suena a dúo de folk rock de los años 60), nombre derivado de sus autores: Whitfield Diffie y Martin Hellman. Según este último habría que añadir a Ralph Merkle como coautor del protocolo.

La base de este protocolo se basa en la dificultad de cálculo del logaritmo discreto de la forma g^a mod p, es decir, averiguar 'a'. Su análogo sería el problema de factorización de números primos que forma la base del algoritmo de clave pública RSA.

Diffie-Hellman se asienta en la forma que hemos visto: g^a mod p. Donde g y p son valores conocidos por ambas partes, es decir, no son valores secretos y pueden ser conocidos por todos. p es un número primo relativamente grande y g es una base matemáticamente relacionada con p (no vamos a profundizar en detalles). Pues bien, aun conociendo g y p, existe una dificultad computacional en hallar el exponente 'a', que es el secreto que va a añadir cada una de las partes.

La parte Alfa enviará a Bravo un valor que será A = g^a mod p. De manera correspondiente Bravo enviará a Alfa su contraparte: B = g^b mod p.

Ahora cada una de las partes tiene un valor que contiene el componente secreto de la otra.

La "magia" de todo esto es que volviendo a aplicar la fórmula sobre los valores intercambiados, ambos tendrán el mismo número, que llamaremos S:

Alfa hará esto:

S = B^a mod p

Bravo por su parte:

S = A^b mod p

Ese número 'S' será la clave "elegida" por ambos. Observemos que en ningún momento 'S' ha sido enviado por el canal, se trata de una derivación que ambas partes pueden hallar de manera común aplicando sus respectivos secretos sobre resultados "imposibles" de computar…hasta hoy…

Entonces llegó un grupo de investigadores de varias universidades junto con gente de la división de investigación y desarrollo de Microsoft. Pensaron que sería buena idea echarle un vistazo a esa tecnología setentera y ver como aguanta los avances en potencia de cálculo y algoritmos de 2015.

En primer lugar se las ingeniaron para lograr un nuevo ataque que degrada las conexiones TLS al uso de Diffie-Hellman en su versión "exportable" (DHE_EXPORT). Esta versión era la que estaba autorizada en los años 90 por la administración Clinton para productos que usaran tecnología de cifrado. Cómo no, esta versión usa primos de hasta 512 bits, una longitud que veremos es insuficiente. Con este ataque, que recuerda poderosamente a FREAK, se aseguraban que las conexiones seguras de una gran mayoría de clientes y servidores usarán Diffie-Hellman con 512 bits.

El siguiente paso era obtener una "base de datos" de cálculos ya efectuados de los primos más usados de 512 bits para esa versión descafeinada de Diffie-Hellman. Con los recursos de cálculo de una universidad, tardaron un par de semanas en obtener estas tablas precalculadas para los dos primos de 512 bits más usados.

Esos dos primos de 512 bits por cierto, son los usados por el servidor Apache y su módulo SSL (mod_ssl). Como ponen de ejemplo, el 8% del índice Alexa del top 1M HTTPS permite o soporta el uso de DHE_EXPORT y usan uno de estos dos primos de 512 bits en un 92% de casos.

Ahora ya solo les queda "escuchar" el resultado de g^a mod p, preguntar en su base de datos y calcular 'a'. Cuando obtienen la forma derivada g^ab mod p, donde 'ab' es la clave usada ya poseen el secreto para descifrar las comunicaciones.

Esto es un resumen a muy alto nivel del ataque. Os invitamos a leer la publicación del grupo de investigadores disponible aquí.

Algo que no pasó por alto al grupo era preguntarse hasta que punto era posible utilizar la misma técnica para valores de 768 y 1024 bits. Básicamente admiten que 768 bits puede alcanzarse de manera realista con una potencia de cálculo distribuido disponible en empresas y universidades y dejan los 1024 bits para organizaciones con muy buenos recursos y dedicados a estos menesteres de manera profesional, léase, la NSA por ejemplo.

No solo lo mencionan en la publicación que describe Logjam. El grupo de investigadores correlacionan directamente las filtraciones de Edward Snowden con la capacidad de la NSA para descifrar comunicaciones VPN usando este tipo de ataque. Casi nada.

¿Qué hacemos ahora? No nos queda otra opción. Es siempre la misma. Parchear y seguir adelante. Este no va a ser el último ataque a la criptografía, al secreto de las comunicaciones y a nuestra privacidad. Esto es una piedra más en el camino como tantas otras piedras llamadas FREAK, CRIME o POODLE y las que quedan por venir.

Por cierto, a los descubridores se les ha olvidado algo "importantísimo". Logjam no tiene un logo molón.

Más información:

Logjam

Imperfect Forward Secrecy:How Diffie-Hellman Fails in Practice

una-al-dia (03/03/2015) FREAK, un nuevo ataque a SSL/TLS

una-al-dia (15/10/2014) SSL tocado y hundido

una-al-dia (07/08/2013) Ataque BREACH, la seguridad HTTPS comprometida en 30 segundos



David García
Twitter: @dgn1729

miércoles, 20 de mayo de 2015

Apple publica la primera actualización para su reloj Apple Watch

Cuando ni siquiera está presente en España _ni en la mayoría de países_ el reloj inteligente de Apple, conocido como Apple Watch, ya recibe la primera actualización de su sistema operativo (Watch OS), con la que se solucionan hasta 13 vulnerabilidades.

Entre las vulnerabilidades corregidas se encuentra la ya famosa FREAK (CVE-2015-1067), conocida desde el pasado 3 de marzo y corregida por Apple en iOS y OS X el pasado 9 de marzo. Curiosamente el Apple Watch se presentó ese mismo día, aunque se puso a la venta en unas pocas tiendas de Apple el 24 de abril. Es decir, cuando el reloj salió a la venta ya incluía una vulnerabilidad grave de la que todo el mundo conocía los detalles.

También se han corregido otras dos vulnerabilidades de ejecución remota de código arbitrario, una al procesar fuentes maliciosas (CVE-2015-1093) y otra por una corrupción de la memoria del kernel (CVE-2015-1101).

También se han solucionado otras siete vulnerabilidades en el kernel, en Foundation, en IOHIDFamily y en IOAcceleratorFamily. Los problemas podrían permitir realizar ataques de denegación de servicio, obtener información sensible, elevar privilegios, redireccionar el tráfico o evitar filtros de red.

Esta actualización de Watch OS, a la versión 1.0.1, también incluye múltiples mejoras en el rendimiento del reloj, de Siri o de las aplicaciones de terceros. También se ha mejorado la interfaz y se incluyen los nuevos "emojis".

Esta actualización se debe instalar a través del iPhone. El reloj tiene que tener al menos un 50% de la batería cargada y estar conectado al cargador. Conectar el iPhone a la WiFi y mantenerlo cerca del reloj durante la actualización. En el iPhone, se debe abrir la aplicación Apple Watch y abrir My Watch > General > Software Update.

Más información:

About the security content of Watch OS 1.0.1
This document describes the security content of Watch OS 1.0.1.

una-al-dia (10/03/2015) Actualización de productos Apple incluye iOS y OS X

FREAK, un nuevo ataque a SSL/TLS



Antonio Ropero

Twitter: @aropero