viernes, 22 de mayo de 2015

Vídeo "Malware en Android y Google Play" de Sergio de los Santos en XI Ciclo Conferencias UPM TASSI 2015

Se encuentra disponible en el canal YouTube de la Universidad Politécnica de Madrid, la sexta conferencia del XI Ciclo UPM TASSI 2015, Temas Avanzados en Seguridad y Sociedad de la Información, de título "Malware en Android y Google Play", presentada el 16 de abril de 2015 en el Campus Sur de la Universidad Politécnica de Madrid por D. Sergio de los Santos, de Eleven Paths.

Acceso al vídeo de la conferencia:

Desde la sección conferencias TASSI del servidor de Criptored, puede descargar además la presentación en pdf utilizada por el ponente y las demás conferencias de este ciclo ya publicadas, así como las de años anteriores.

Presentación:

XI Ciclo TASSI:



Jorge Ramió Aguirre
Coordinador conferencias TASSI


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