El futuro de la mula y similares

---

Estos días han salido bastantes cosillas sobre el uso y la regulación del P2P aquí en España. Primero, que iban a promulgar nuevas leyes para combatirlo, implicando a las operadoras en la lucha. Luego, que no sólo no iban a hacer nada, sino que se va a obligar a las operadoras a dar realmente el ancho de banda que prometen (mínimo de un 80% de lo prometido) lo que viene de perlas para el P2P.

En otros sitios ya hay medidas aplicadas, parece ser: en Francia está el modelo de los tres avisos, y en Reino Unido, se lo guisan y se lo comen las propias operadoras, sin que nadie les diga que tienen que hacerlo. Los suecos también hacen sus pinitos, aunque sólo para husmear en lo que la gente se descarga, y por eso ya hay iniciativas para dar soluciones criptográficas al P2P.

Veremos en qué queda...

Cuidado con lo que dicen las herramientas

---

Creo que a estas alturas, todo el mundo se ha enterado del fallo gordo de OpenSSL en Debian (y derivados). Casi nada: el generador de números aleatorios es predecible. Cualquier herramienta que utilizara ese generador para securizar los datos que transmite podría ser vulnerable, al ser posible, offline, descifrar ese tráfico. Cualquier servidor SSH que use claves generadas por el sistema vulnerable podría ser objeto de man-in-the-middle, y el usuario ni se enteraría.

El problema vino al corregir un fallo detectado al usar dos herramientas de análisis dinámico (Valgrind y Purify), que indicaban que se estaba usando memoria no inicializada. Esto sería un defecto en otras aplicaciones, pero en este caso, se estaba usando para inicializar la semilla con que se genera el número aleatorio necesario para crear las claves criptográficas. Para corregir el problema, se eliminó algo más de código del necesario, debido a que no se sabía muy bien qué hacía, con el resultado de que ese número aleatorio tiene muy poca entropía.

A lo que voy: el problema viene por una costumbre muy común en los programadores, y muy mala, que es "comentar y a ver qué pasa", cuando el código no se comprende. ¡Cuidado con lo que dice una herramienta!. El bug original era, en este caso, un falso positivo de las herramientas (yo lo considero así) y hay que discernirlo correctamente. Eso sí, creo que el que sabe hacerlo siempre es un programador de bandera (todos podemos cometer un fallo, ¿no?).

Me ha gustado mucho el chiste que se ha puesto en la página de Metasploit:


Más enlaces:
el fallo reportado
sitio del descubridor
exploit posible

Actualización: preguntas frecuentes

Negación admisible (usando criptografía)

---

Imagina que guardamos información confidencial en nuestros ordenadores, en un fichero o disco cifrado, y que somos obligados a dar nuestras credenciales para acceder a esos datos, por chantaje, amenazas o por la fuerza. Parece ser que, por ejemplo, en Reino Unido, un investigador (policía, se entiende) puede obligarte a darle lo que necesite (contraseña...) para acceder a tus datos cifrados.

He leído todo esto en el último Phrack Magazine, el número 65, concretamente en el artículo The only laws on the Internet are assembly and RFCs. No es una idea nueva, otros ya han hablado de ello, aunque yo, personalmente, no lo había oído. Me ha parecido muy interesante. Expone otras ideas, pero comentarlas se merece al menos una entrada aparte.

Al lío: una contramedida tecnológica en caso de que alguien sea obligado a dar credenciales para acceder a ficheros cifrados, es la posibilidad de negar que la información que se quiere proteger esté en ese fichero cifrado. Se trataría, básicamente, de generar duda sobre si la información que el investigador está buscando está ahí o no. Se indican tres herramientas que emplean este tipo de estrategia:

• TrueCrypt: conocidísima utilidad de cifrado de disco. Hasta que sea descifrado, el espacio que ocupa un fichero o un disco cifrado tiene la apariencia de basura. Además, está la posibilidad de crear volúmenes ocultos.
  
• OTR (Off-the-Record messaging): proporciona cifrado fuerte para aplicaciones de mensajería instantánea. Después de autenticar al usuario, todos los mensajes son cifrados pero no firmados digitalmente, de forma que no se puede asegurar el origen.
  
• 2c2/4c: tomará como entrada dos ficheros, y generará como salida un único fichero que contendrá a los dos. Dependiendo de la contraseña que se introduzca para descifrar el fichero generado, devolverá uno u otro de los de la entrada.

El artículo en sí, después de esta introducción, nos detalla el funcionamiento de una nueva utilidad, de nombre Elettra. Su concepto es similar al de 2c2/4c: dados N ficheros de entrada, cada uno con una contraseña diferente para obtenerlo después, generar un único fichero de salida con todos ellos cifrados. Pero además, se agregará algo de basurilla, de forma que, por el tamaño del fichero de salida, no se pueda saber si hay N o N+1 ficheros cifrados ahí dentro. Así, el investigador se irá contento con las contraseñas que conoce, pero sin el fichero que realmente se desea proteger.

¿A que es una buena cosa?