Foro Wifi-libre.com

Eminentes investigadores especializados en criptografía demuestran como la NSA es capaz de descifrar gran parte de los datos supuestamente seguros ( VPN, SSL, https, TLS ) 

  Los documentos desvelados por Snowden  han dejado claro que la NSA es capaz de, por ejemplo, descifrar los datos que pasan por un VPN.
Desgraciadamente los documentos no dan los detalles matemáticos o técnicos sobre el procedimiento empleado por la agencia Norte Americana. 
Dan indicaciones concretas y describen sumamente el proceso seguido por la "suite" de la NSA.

Para "crackear" un VPN la NSA esnifa el trafico (cifrado)
Selecciona en este trafico unos datos concretos que se mandan a su supercomputadora
La supercomputadora devuelva la llave al agente y puede descifrar los datos que le interesa.
    Esto se sabe.
Lo que no se sabe (se sabía) es exactamente como esto es posible.
  Es sumamente importante entender concretamente como hace la NSA para poder tomar la contras-medidas adecuados y proteger correctamente las comunicaciones en la red.

  Y es lo que hicieron 14 investigadores, unos especialistas de fama mundial en criptografía informática procedentes del CNRS (El mejor centro para la Investigación en ciencias fundamentales en Francia) , microsoft reserach, la universidad de Michigan...   
  Han publicado el resultado de sus investigaciones en un articulo que ha ganado el premio a la mejor publicación del año 2015 en el CCS.

• Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice

Vulnerabilidad a nivel del intercambio de llaves "Diffie Hellman"

  Si has seguido de cerca las noticias en el mundo del crack wifi, habrás oído hablar del intercambio de llaves Diffie-Hellman con el ataque WPS "pixie dust"  ( cf: "Pixie Dust" ataque de fuerza bruta offline para generar el PIN valido )
  El intercambio de llave Deffie hellman es fundamental en criptografía moderna "asimétrica" (la buena) y se emplea abundantemente.
  Es seguro si se implementa correctamente y si se evaluá correctamente los medios de los cuales disponen las fuerzas adversarias.
  Y lo que ocurre con IPsec, TLS https... es similar (en otras proporciones) a la brecha "pixie dust" y se debe también a unos niveles mínimos de entropía no respectados en la implementación del intercambio DH.
    Recuerdo que en un intercambia de llaves Diffie Hellman se hace asi (de forma asimétrica)
  "Bob" (uno de los dos actores en la comunicación cifrada) y "Alice" (el otro actor) se ponen de acuerdo sobre el valor de p y g

• p es un numero muy alto

• g es un numero primario "modulo p" (Aritmética modular)

    b y g no son secretos.   
   Luego cada uno forma su elige una llave privada ( a y b ) y generan cada uno una cadena (A y B) para intercambiarlas

• Alice : A=g^a (mod p)

• Bob : B=g^b (mod p)

  Llegamos a una llave secreta comuna que se calcula así :  g^(a*b) modulo p
  a y b son secretos
Y se supone que no se puede calcular la llave teniendo solo p y g.
Pero en la practica no es así para gran parte de los sitios, VPN etc..

  Si la implementación no es optima, con la potencia suficiente podemos crear tablas precomputadas (al igual de lo que hacemos con cowpatty para el crack WPA)

Con TLS (la versión moderna de SSL) , el servidor y el cliente obtienen unos logs.

• Alice va a a generar y de este modo :  y=g^a  

• Bob generará z de este modo : z=g^b

las tablas precomputadas sirven para deducir a con valores de y de tal forma que caímos en y=g^a (mod p)
Luego podremos generar la llave TLS : K=z^a=g^{a.b} (el secreto)
  Los investigadores han llamado este ataque "logjam" y es así que la NSA ha sido capaz de explotar esta vulnerabilidad en intercambios Diffie-Hellman de 1024-bit
y lograr descifrar las comunicaciones a través de un VPN.

 
  Los investigadores han hecho pruebas a pequeña escala  sobre DHE de 512 bits para evaluar los recursos necesarios para petar un DHE de 1024-bits.
Han hecho tablas precomputadas para los dos números primarios los más empleado cuando se usan DHE de 512 bits

Normalmente los sitios usan llaves 1024bits... No obstante han obtenido resultados probantes : 8.5% del millón de sitios los mas visitado.

1024bits de entropia a reventar no es el doble de 512bits; es muchísimo más, esto es exponencial..
¿Es possible romper 1024bits?

Yes we scan !

Romper un numero primero y crear las tablas necesita unos recursos extraordinarios.
Para construir tal maquina los investigadores han estimado que se necesitaría cienes de millones de dolares.
  ... Un coste perfectamente asumible por la NSA con su presupuesto de 10 billlones de dolares en 2013 de los cuales 1 billón va al departamento de criptologia,
Tal maquina podría crackear un solo numero al año.
  ¿Vale la pena?
Si.
  Porque muchos sitos usan implementaciones por defecto-estandardiza y con un par de grupos precomputados (dos años de trabajo) se podría descifrar... 66% de los VPN IPsec  :

  Hablamos de tiempo y dinero que solo pueden invertir entidades como la NSA... pero nada nos dice que otros estados no hacen o están a punto de hacer lo mismo.

Resolver el problema

   
  Lo primero que hay que hacer es "difundir la palabra".

• Las llaves DH de 768bits no son bastante seguras y se pueden romper con recursos como los de las universidades prestigiosas que hicieron el estudio

• Mal configuradas, las llaves DH de 1024bits son suseptibles de ser rotas por agencia con recursos extraordinarios

  Tiene que haber mas comunicación y interacciones entre universitarios/investigadores y "webmasters/desarrolladores"
  La idea sería que todo el mundo tome buenos hábitos, en fase con la realidad, para estar un paso por adelante

• Adoptar ECDH : Es decir Diffie Hellman con "curva elíptica" . El proceso es mas liviano que con "mod p" y sobre todo no permite hacer precomputación gracias a los logs. El ataque jamlog descrito en el paper es imposible 

• Fortalecer las llaves Diffie Hellman : Lo suyo sería que se generalice directamente el uso de llaves de 2048bits

• Evitar los grupos predeterminados para los sistemas que requieren una compatibilidad con llaves de 1024bits

  Los investigadores han comunicado los resultados a empresas como Safari, Opera... cuyos software aceptaban números primarios de 512bits (safari incluso menos)
Han rectificado el tiro con llaves de 1024 bits correctamente configuradas.
  Los desarrolladores de Servicios TLS han tomado nota y trabajan a la implementación una nueva extensión que rechaza las llaves de menos de 2048bits.