Funciones Hash.

Vamos a explicar en este artículo las funciones Hash. Seguramente todos hemos oido hablar de ellas, pero pocos tendrán claro lo que son realmente y como funcionan.
El artículo empezará desde cero e irá aumentando su nivel progresivamente hasta lograr una descripción total de este tipo de funciones.


Que es un Hash?

Si vamos a la definición de Wikipedia, nos dice "En informática, una función hash o algoritmo hash es una función para sumarizar o identificar probabilísticamente un gran conjunto de información, dando como resultado un conjunto imagen finito generalmente menor ..."

Muy bonito todo, pero como he dicho, voy a comenzar este artículo desde cero, paso a paso y despacito, para que todo el mundo pueda seguir por lo menos el principio.

Una función hash es un algoritmo matemático que nos da un resultado B al aplicarlo a un valor inicial A. Es como cualquier función matemática, por ejemplo la función raiz cuadrada nos daría como resultado 2 si se la aplicamos al número 4. E igual que cualquie función matemática tiene que actuar de tal forma y tiene que cumplir con ciertos criterios. No nos puede devolver cualquier cosa, lo que nos devuelva requiere que tenga ciertas propiedades para que podamos usarlo.


Que propiedades tienen que cumplir las funciones hash?

1- Sea cual sea la longitud del texto base A, la longitud de su hash resultante B siempre va a ser la misma. Por ejemplo, si la longitud de la salida B esta defiinida en 128 bits, si aplicamos una función hash a un A de 5 bits nos dará un B de 128 bits, y si se la aplicamos a un A de 380 millones de bits, nos dará un B de 128 bits igualmente.

2- Para cada entrada A, la función generará una salida B única. O lo que es lo mismo, es imposible que dos textos bases A y A' tengan un mismo hash B.

Según estas dos primeras propiedades, nos damos cuenta enseguida de la utilidad de las funciones de hash.

La más inmediata es usarla para generar un resumen de algo. De hecho, estas funciones se conocen también como funciones resumen. Un ejemplo real puede ser el del típico repositorio de documentos. Si alguien quiere almacenar digamos "Las_Aventuras_Del_Ingenioso.doc" cuyo contenido es El Quijote enterito, el sistema lo primero que tiene que hacer es revisar que no está previamente ya almacenado con el mismo o con otro nombre, por ejemplo "ElQuijote.doc". El sistema puede comparar letra a letras el documento de entrada con todos los docs de su BBDD para comprobar que no está, o puede comparar el resumen del documento de entrada con los resúmenes de los documentos de la BBDD, opción mucho más manejable y rápida.

Además, como la salida B es única para cada A, se puede usar también para verificar la integridad de A. Podemos ver que muchos programas incluyen su hash junto con su descarga, de esta forma, podemos verificar que el programa no ha sido modificado ni le han introducido un virus o ha sido troyanizado. Si a los bytes de una aplicación A les calculo el hash B y lo adjunto, cuando alguien modifique la aplicación A, al calcular de nuevo su hash su valor habrá cambiado y será distinto de B.

Podeis probar a calcular el md5 de un documento, luego modificais una simple coma del documento y calculais de nuevo el MD5. Vereis como ha cambiado completamente, aunque solo hemos modificado una simple coma.

3- Dado un texto base, es fácil y rápido (para un ordenador) calcular su número resumen.

4- Es imposible reconstruir el texto base a partir del número resumen.

Esto es lo que se conoce como One-Way hash functions. A partir del hash es imposible reconstruir el texto base.
Atención aquí !!!, no quiero que os lieis. Este es un punto que muchos no teneis claro. Solo hay que leer bien, a partir del hash B es imposible sacar el texto A, quiere decir no existe forma o es computacionalmente imposible, que mediante operaciones matemáticas inversas o no a las del algoritmo de hash, se llegue desde B al texto base.

Si os dais cuenta, esto es muy distinto que usar fuerza bruta. No tiene nada que ver. Con fuerza bruta le aplicamos la función de hash a diferentes textos hasta que obtenemos un hash similar al hash del texto que buscamos, con lo que por consecuencia tendremos el texto buscado.

Nuestra función hash.

Vamos a inventarnos un ejemplo para verlo claramente. Esto no podría tomarse como una función hash fiable porque es demasiado débil a ataques, pero nos vale como ejemplo gráfico por si no ha quedado del todo claro.

Esta función hash de nuestro ejemplo lo que hace es traducir cada caracter del texto A  de entrada en su equivalente código ASCII, los agrupa de 3 en 3 y les aplica la función matemática (1º - 2º) * 3º.


Como vemos, el valor de nuestra función hash aplicada al texto base A "En un lugar de la Mancha de cu" es -19631.

Cumple la propiedad 1, (o casi), con un poquito más de desarrollo se puede hacer que el tamaño del hash devuelto sea siempre el mismo.

Cumple con la 2, el valor del hash es único para cada texto. Si modificamos lo más mínimo la frase, el valor cambia.

Cumple con la 3 ya que es inmediato sacar el resultado y con la 4, ya que a partir del -19631 no se puede llegar al texto.

5. - No puede presentar Colisiones.

Que son las colisiones?

Según la primera caracteristica que hemos visto de las funciones hash, que nos dice que el tamaño del hash B resultante de A es siempre el mismo, deducimos que no puede cumplirse la segunda caracterisitca, que dice que el hash B tiene que ser único para cada A.

Por ejemplo, la función MD5 nos devuelve un hash de 128 bits. Para que cada hash equivalga a un unico texto base, tendría que existir solamente un texto por cada combinación del hash devuelto, o sea, tendría que haber solamente 2^128 textos distintos, lo cual no es cierto. Como textos distintos hay infinitos, podemos decir que hay infinitas posibilidades de que dos textos tengan el mismo hash.

Esto es lo que se conoce como colisiones.

Seguramente las hemos visto muchas veces sin darnos cuenta de que pasaba. Hay muchos sistemas que requieren contraseñas de uso, como pueden ser los sistemas de foros y demás, donde lo que se almacena no es la contraseña, sino el hash de esa contraseña. Esto no se hace con el propósito de resumir la contraseña, seguramente será mas corta que el hash generado, se hace con el propósito de que si alguien tiene acceso al almacén de contraseñas, o si alguien desensambla la aplicación proteguida, etc, no pueda ver la contraseña en plano y siga sin acceso (a no ser que la crackee por fuerza bruta si conoce el algoritmo de la función).
Os habeis encontrado alguna vez con algún programa que te pide una contraseña para acceder a algo, le metes el crackeador, y te da acceso pero sin darte la clave? Creo recordar que en el Excel95 o 97, el programa que desprotejía las hojas o las celdas, funcionaba así, te desproteguía la hoja pero no te daba la clave.

Eso es porque el algoritmo de la función hash que usan para las contraseñas es tan simple como el que hemos puesto de ejemplo, y tiene multiples colisiones muy fáciles de encontrar. Así que en vez de buscar la contraseña se buscaban colisiones a ese hash, contraseñas alternativas que tenían el mismo hash que la contraseña verdadera.

La fortaleza de una función hash requiere que estas colisiones sean las mínimas posibles y que encontrarlas sea lo más dificil posible.

Bien, hasta aquí llega la parte básica de las funciones hash. Se explica su funcionamiento general, sus propiedades y sus usos.
Ya no teneis excusa para preguntar como descifrar un hash, creo que ha quedado bien claro que los hashes no son un método de cifrado y que desde el resultado no se puede obtener el texto base más que por fuerza bruta.


Propiedades de una función hash con respecto a las colisiones.

Las propiedades que deben de tener las primitivas hash son:

1. Resistencia a la preimagen: One Way Hash Function. Como hemos dicho antes, significa que dada cualquier imagen, es computacionalmente imposible encontrar un mensaje x tal que h(x)=y. Otra forma como se conoce esta propiedad es que h sea de un solo sentido.

2. Resistencia a 2° preimagen: OWHF: Weak One Way Hash Function. Significa que dado x, es computacionalmente imposible encontrar una x’ tal que h(x)=h(x’). Otra forma de conocer esta propiedad es que h sea resistente a una colisión suave.

3. Resistencia a colisión: CRHF: Strong One Way Hash Function. Significa que es computacionalmente imposible encontrar dos diferentes mensajes x, x’ tal que h(x)=h(x’). Esta propiedad también se conoce como resistencia a colisión fuerte.

Vamos a poner unos ejemplos para ver la necesidad de estas propiedades:

Vamos a establecer un escenario de firma digital.

Un documento X se adjunta con su firma, que consiste en clacular el hash de X, h(X), y en cifrarlo, C(h(X)) con la clave privada del remitente o propietario.
Para verificar la integridad de X, el destinatario o la persona correspondiente descifra con la clave pública del propietario el C(h(X)) para obtener el h(X) inicial, calcula de nuevo el h(X) del documento y los compara. Si el h(X) inicial es igual al h(X) nuevo es que ese documento no ha sido modificado y que pertenece al firmante.

Si esa función de hash no tiene resintencia a una 2ª preimagen, un atacante C que podría encontrar un mensaje X' tal que h(X') = h(X), y reclamar que el documento firmado no es X sino X'.

O imaginemos que C tiene que presentar para firmar por un tercero un documento X, y a la vez redacta otro documento Y. Si la función hash no tiene resistencia a las colisiones, C puede añadir información basura a X e Y (X' e Y') de forma que h(X+X') = h(Y+Y'). Entonces el que firme X también está firmando Y.

Por último si (e,n) es la clave pública RSA de A, C puede elegir aleatoriamente un y y calcular z = ye mod n, y reclamar que y es la firma de z, si C puede encontrar una preimagen x tal que z = h(x), donde x es importante para A. Esto es evitable si h es resistente a preimagen.


Algoritmo MD5

El algoritmo MD5 realiza las siguientes operaciones:

1. Adición de bits de relleno:
El mensaje es rellenado o ampliado para que su longitud en bits sea congruente a 448 módulo 512. Esto debe ser así puesto que hay que reservar 64 bits para la adición de la longitud del mensaje en el próximo paso. Así pues, si no se llega a la anterior congruencia, se añadirá el relleno, consistente en un bit ‘1’ seguido de tantos bits ‘0’ como se precisen.
La razón de porqué un uno seguido de ceros se debe que si se emplea sólo relleno con un valor (por ejemplo todo ceros) el proceso no sería reversible a la hora de eliminar dicho relleno.

De todas maneras, siempre se realiza esta operación de relleno, aunque la longitud del mensaje ya sea congruente a 448 en módulo 512. Por ello, se añadirán como mínimo 1 bit de relleno, y como máximo 512 bits. Obsérvese la siguiente figura:


2. Adición de representación binaria de longitud del mensaje:
Posteriormente se añade al mensaje (con el relleno realizado) una representación de la longitud del mensaje antes de ser rellenado. Dicha representación tendrá una longitud de 64 bits (16 palabras de 32 bits, es decir, dos enteros de 4 octetos cada uno). En el caso de que el mensaje sea mayor de  bits, sólo se tendrán en cuenta los 64 bits menos representativos, que es lo mismo que decir que esta representación de la longitud del mensaje está realizada en módulo.

El mensaje tiene ahora un número de bits múltiplo de 512, por lo que habrá un número entero de palabras de 32 bits (enteros de 4 octetos), concretamente 512 / 32 = 16, de lo que se puede concluir que si hay b bloques de 512 bits cada uno que forman el mensaje, entonces el mensaje tendrá n palabras de 32 bits: n = 16 * b

3. Inicializar buffer MD:
Para poder calcular el valor hash o resumen  se necesita tener un buffer de 4 palabras de 32 bits (A, B, C, D), pero antes de comenzar con el proceso se los ha de inicializar con algún valor determinado, que Rivest establece:

Palabra A = 01 23 45 67 67 45 23 01
Palabra B = 89 ab cd ef ef cd ab 89
Palabra C = fe dc ba 98 98 ba dc fe
Palabra D = 76 54 32 10 10 32 54 76

En la primera columna los valores hexadecimales están ordenados de modo que los valores menos significativos aparecen en primer lugar (notación empleada por Rivest en la implementación de este algoritmo), y en la segunda los valores más significativos están a la izquierda (posiciones más altas de la memoria en Intel 80xxx)

La razón de ver estas formas de representar los mismos valores se debe a intentar evitar confusiones, pues en función del tipo y arquitectura de la máquina  sobre la que ha de trabajar el algoritmo, este sufrirá adaptaciones en dichos valores al realizar la implementación. Ello es debido a las distintas formas en que se almacenan los datos en memoria en las distintas arquitecturas (Intel, Sun, Sparc, ...)

Los algoritmos MD4 y MD5  están pensados para facilitar su implementación en arquitecturas denominadas little-endian. Este formato asume que el byte menos significativo de una palabra se almacena en la posición más baja, y el byte más significativo en la parte más alta. Es el formato que emplean los procesadores Intel 80xxx que integran los PC domésticos.

4. Procesar el mensaje en bloques de 512 bits:
Esta es la parte central del algoritmo. Aquí se definen las cuatro funciones que se emplearán en las cuatro vueltas que se aplicarán sobre cada bloque. Véase la siguiente figura:


Estas cuatro funciones reciben como parámetros de entrada tres palabras de 32 bits cada una (tres enteros de 4 bytes de longitud) y devuelven como salida una. Son las siguientes:

F(X, Y, Z) = (X and Y) or ((not X) and Z)
G(X, Y, Z) = (X and Z) or (Y and (not Z))
H(X, Y, Z) = X  Y  Z
I(X, Y, Z) = Y  (X or (not Z))

Donde F funciona como una sentencia condicional if en programación tradicional: Sí X = 1 entonces Y será 1 de lo contrario Z será 1.

G también funciona de manera condicional como F: Si Z = 1 entonces X será 1 de lo contrario Y será 1.
H simplemente realiza la operación OR-Exclusiva (XOR) de X, Y y Z.
I realiza la operación XOR con X si es 1 o si Z es 0.

Por otro lado MD5 no utiliza las constantes (‘magic’ constants) que se empleaban en MD4. En su lugar se emplea una tabla de 64 elementos construida a partir de la función trigonométrica seno. Sea T  el elemento i-ésimo de dicha tabla, que será igual a la parte entera de 4294967296 veces abs(sen(i)), donde i está expresada en radianes. Puesto que hay que realizar 16 pasos en cada una de las cuatro vueltas, es decir, 64 operaciones, la idea es usar una constante de la anterior tabla para cada vuelta.

5. Recoger el valor hash de salida:

El valor hash de salida se obtiene de los registros A, B, C y D donde el octeto más representativo es D y el que menos A.


Ataques

Ataque de Cumpleaños.

El ataque más conocido (de fuerza bruta) a una función hash es conocido como "birthday attack" y se basa en la siguiente paradoja.

Cual es la cantida de personas que hay que poner en una habitación para que la probabilidad de que el cumpleaños de una de ellas sea el mismo día que el mio?

Debemos calcular un tal que n(1/365) > 0.5, luego n > 182.

Sin embargo, cual sería la cantidad de personas necesarias para que dos cualesquiera de ellas cumplan años el mismo dia?

Cada pareja tiene un probabilidad de 1/365, y en un grupo de n personas hay n(n-1)/2 parejas diferentes, luego
(n(n-1)/2)(1/365) > 0.5

Esto se cumple si n>23, una cantidad sorprendente mas pequeña que 182.

La consecuencia de esta paradoja es que aunque es muy dificil dado un x calcular un x' tal que h(x) = h(x'), resulta mucho más fácil buscar dos valores aleatorios x y x' tal que h(x) = h(x´).

Esto en la práctica significa que un hash de n bits permitiría una colisión de 2º preimagen o débil una vez de cada 2^n, pero producirá una colisión fuerte una vez de cada 2^(n/2).

En el caso de un hash de 64 bits necesitaríamos 2^64 mensajes dado un x para obtener el x', pero bastaría generar 2^32 mensajes aleatorios para que aparecieran dos con el mismo hash. El primer ataque nos llevaría 600.000 años en un ordenador que generara un millón de mensajes por segundo, mientras que el segundo apenas necesitaría unas horas.

Ataque Wang-Yin-Yu o Ataque chino

Supongo que muchos habreis leído actualmente que las funciones hash MD5 y SHA1 han sido rotas por un grupo de matemáticos chinos y que ya no sirven para nada y demás.

Vamos a tratar de explicar esto para que todo el mundo pueda evaluar el grado de ruptura de estas funciones, porque se habla mucho de esto en los foros, pero no se evalua hasta que punto nos afecta.

Como hemos visto en el Ataque de Cumpleaños, para encontrar dos mensajes X y X' aleatorios que tengan el mismo SHA-1 (160 bits) por ejemplo, por fuerza bruta se necesitarían generar 2^(160/2) mensajes.

Pues bien, este grupo de matemáticos ha descubierto un sistema que permite hacer esto con un esfuerzo menor que por fuerza bruta.

En concreto para el SHA1, pueden encontrar una "colisión de cumpleaños" con un esfuerzo equivalente a 2^69 operaciones hash, en vez de las 2^80 requeridas por fuerza bruta.

Como podemos ver, este es una ataque contra las colisiones fuertes, pero no contra las colisiones de 2 preimagen, a las cuales no afecta. Si alguien quiere generar un mensaje x' que tenga el mismo SHA1 que un mensaje x ya existente, tiene que seguir generando 2^160 mensajes para conseguirlo.

Y aunque el "ataque de cumpleaños" contra SHA1 se ha vuelto 2000 veces más rápido, sigue siendo del orden de 10.000 veces más dificil que un ataque contra un DES, que no está al alcance de todo el mundo.

Ahora bien, existen casos en que las implicaciones son importantes.

Imaginemos que redacto un contrato A de venta de un inmueble en word, al cual le adjunto varios jpgs con fotografías del inmueble.

Al mismo tiempo genero un contrato alternativo A' con las mismas fotos pero modificando el precio de venta a mi favor.

Es prácticamente imposible que el h(A) = h(A').

Sin embargo puedo crear múltiples versiones de A y de A', modificando aleatoriamente bits de las fotografías (se podría hacer modificando el texto, añadiendo espacios, cambiando cosas no significativas, etc, pero quedaría un texto muy sucio y se notaría la "trampa". Pero modificando bits de las fotografías como mucho perderé algo de calidad), hasta conseguir dos versiones que tengan el mismo hash.

Le presento al comprador la versión de A, acepta las condiciones y lo firma electrónicamente. Cambio la variante de A por la de A' y ya tengo un contrato legal de compraventa firmado con unas condiciones distintas de lo establecido.

Si la función hash que se va a utilizar para realizar la firma es por ejemplo un SHA1, mediante el ataque tri-chino tendré que generar 2^69 variantes de A y 2^69 variantes de A', que como hemos visto antes, aunque no esté al alcance de cualquiera, es factible.

Pero si la función hash es por ejemplo un MD5, solo tendré que generar 2^32 variantes de A y 2^32 variantes de A', que está al alcance de cualquier PC.

Ataque Multicolision de Joux-Wang.

Si nos fijamos en el funcionamiento del algoritmo MD5, vemos el mensaje se divide en bloques de 512 bits. El primer bloque es "hasheado" usando como parámetro el vector de inicialización y dando como resultado otro vector de 128 bits, que sirve como inicialización para el siguiente bloque de 512 bits, y así sucesivamente.

Entonces se hace obvio que si tengo dos n*bloques A y B, siendo A != B, que cumplen que MD5(A) = MD5(B), si les añado un "payload" Q, entonces MD5(A+Q) = MD5(B+Q).


Como posible prueba de concepto de esto os remito a un artículo de Eduardo Díaz, http://www.codeproject.com/dotnet/HackingMd5.asp.

El desarrollo ahí mostrado como ejemplo, se basa en una aplicación que ejecuta archivos en un formato propietario de distribución. Tenemos un ejecutable goodexe.exe que antes de distribuirlo se convierte a su formato .bin, y un programa "extractor" que ejecuta ese .bin.

También tiene un ejecutable devilexe.exe que se supone que es el malware.

Lo que hace su aplicación es, teniendo un vector A y otro B tal que MD5(A) = MD5(B), genera el good.bin haciendo A + goodexe.exe + evilexe.exe, y genera el evil.bin haciendo B + goodeexe.exe + evilexe.exe. De esta forma, MD5(good.bin) = MD5(evil.bin).

Luego el programa extractor, mirando si el .bin tiene A o tiene B, ejecuta goodexe o evilexe.

De esta forma puedes colgar good.bin en la red, y mas tarde sustituirlo por evil.bin (previamente renombrado por supuesto).

Como los MD5 son iguales, nadie se dudará, y ejecutará otro programa distinto.

Personalmente no le veo utilidad a este ejemplo, es como distribuir un troyano solo que la fecha de activación la decides tú al cambiar de versión.


"La historia de Alicia y su jefe"

Hay otro ejemplo que si es más interesante.

Aquí podeis ver dos cartas en PostScript distintas dentro del mismo contexto cuyo MD5 es el mismo en ambas:
http://www.cits.rub.de/MD5Collisions/

Al firmar una, que es una carta de recomendación normal y corriente, estás firmando la otra, que es una carta que te da acceso a unos secretos.

Los creadores de estas cartas no dan detalles técnicos a cerca de como se hace esto, aunque dicen que están preparando una documentación que lo explica.

Pero a nosotros no nos gusta esperar, así que detallamos el procedimiento en exclusiva.

Si editamos ambos .ps, vemos que el codigo es algo tal que asi:


Quizás os despiste un poco porque el código está en notación polaca inversa, pero si nos fijamos en la línea de los caracteres raros, lo que está haciendo es comparar todo lo que hay dentro del primer paréntesis con lo que hay dentro del segundo.

Si son iguales devuelve True, y se ejecuta el código del primer bloque {}, que es el que corresponde al de la carta de recomendación, y si no son iguales ejecuta el código del siguiente bloque {}, que es la carta que da poderes.

Ahora abrimos ambos .ps con un editor hexadecimal y nos fijamos en como está la estructura diviéndola en bloques de 64 bytes.

[/size]

[/size]

Por qué 64 bytes? Porque como hemos dicho antes, el algoritmo MD5 va "hasheando" de 512 en 512 bits (64 bytes).

Así que vemos que el primer bloque de 64 bytes es común en ambos .ps, dado que es la cabecera, que ha sido retocada convenientemente para que ocupe exactamente eso.

Bien, y también vemos que los siguientes dos bloques de 64 bytes corresponden exactamente a los caracteres del primer paréntesis.
Estos dos bloques difieren de un ps a otro.

A partir del 4 bloque, ya todo es común para ambos .ps.

Ahora ya todo se ve más claro.

Han montado la cabecera Cab para que ocupe 64 bytes. Luego han creado dos versiones A y B añadiendo 128 bytes aleatoriamente buscando una colisión tal que MD5(Cab + A) = MD5(Cab + B).

En este punto, como el resto del código es igual para ambos documentos, ambos documentos compartiran hash, así que lo que se hace es mirar si el documento tiene A o B para enseñar una carta o la otra.





Estado actual de las funciones Hash.

La función hash MD4 está totalmente rota y descatalogada, de hecho existen algoritmos que encuentran colisiones en pocos segundos.

Para el uso del MD5 hay que tomar ciertas precauciones, pero cualquiera que se haya leido este artículo está capacitado para tomarlas. Lo mejor es no usarlo, pero si no nos queda más remedio, usándolo con cuidado es perfectamente seguro. Por ejemplo no firmeis nada usando MD5 si el que redacta el documento a firmar es parte interesada, o antes de firmarlo modificad algo del documento, o guardad copia, etc.

Para SHA1, yo no diría como se dice en muchos sitios que el edificio está en llamas y que estamos perdidos. Lo único es que las alarmas suenan, aunque no veamos aún el humo, y lo prudente es ir hacia la salida de emergencia, pero no hace falta correr ni que cunda el pánico. Pero tampoco hay que quedarse en el sitio, porque los ataques criptoanalíticos cada día mejoran, y cada será más fácil y rápido.

La solución que se está dando a esta problemática es ir incrementando el tamaño de los hashes. PGP ya usa SHA256, etc. Pero es solamente un parche. Estos algoritmos son todos monocultivo, y dándoles mas bits solo incrementas el esfuerzo para encontrar colisiones. Pero según avancen los métodos de criptoanálisis y la potencia de los ordenadores, se irán recortando los tiempos, y estaremos en las mismas.

El punto más crítico es el legal. Todo lo que se firme con un certificado legal o con el futuro DNI electrónico, tiene el mismo valor que una firma manuscrita.

Esta consideración legal se sustenta entre otras cosas en que el algoritmo de hash de la firma funciona como tiene que ser y que el hash resultante es único para el texto firmado.

Si un sistema no puede garantizar que es tal el documento que has firmado, y que no hay posibilidad de que te hayan dado el cambiazo con otro documento que tiene el mismo hash, todos los documentos firmados por esa aplicación no serán legales.

Teneis el caso de las fotografias de tráfico de Australia sin ir más lejos:
http://www.hispasec.com/unaaldia/2489

Solución? Muy simple. Usando dobles hashes.
La gente no le da la importancia que tiene al problema de las colisiones, y si se la dan, por ejemplo PHP, no lo solucionan como es debido.

Si para firmar algo en vez de cifrar el MD5 o el SHA1 o el SHA256 del documento, se cifrara una concatenación por ejemplo de MD5+SHA1, habría que buscar una colisión doble para conseguir un documento alternativo, lo que actualmente es imposible.

Si teneis que usar las firmas electrónicas para vuestros documentos, y se van a firmar por ejemplo usando MD5, añadidles un campo estilo fingerprint con el hash del documento en SHA1.

Buenas a todos,

Este foro está dedicado a todo lo relacionado con la criptografía. Algoritmos, aplicaciones, rupturas, seguridad, legalidad, instalación, configuración, etc.

Los post del estilo quiero descifrar esto y demás los podeis postear en Wargames si quereis, pero de aquí serán movidos o serán borrados.

Salvo este tipo de posts y casos particulares, todo lo demás será bien recibido siempre que contenga un mínimo de calidad.

Gracias por seguir las normas y esperamos que esta nueva sección sea de vuestro agrado.

Reglas Generales

Agregado 04/10/2010:

Cualquier pedido de ayuda sobre los retos de Warzone, deben de ser tratados en el subforo de Warzone.
Todo thread sobre los retos de Warzone, será movido al subforo correspondiente y en caso de que ya existiese un thread al respecto, se eliminará directamente.

APOKLIPTICO

Ya está disponible el documento "Taller de Criptografía" bajo licencia libre GFDL de Death Master.

Death Master:

Links de descarga
http://www.telefonica.net/web2/thedeathmaster/articles/tall_cript/taller_de_criptografia_by_death_master.zip

Gracias a tí, Death, por este material de primera.
Ya sabes que estás en tu casa.


Actualización: jueves, 3 de julio del 2008

Se añade una nueva dirección para la descarga del archivo:

http://rapidshare.com/files/126841970/taller_de_criptografia_by_death_master.zip.html

1.  Cracking al PIN de BlueTooth.

  1.1.  Introducción.

  Debido a la reciente publicación de este método, y al interés general que ha suscitado, nos adelantamos a su publicación y lo hacemos en forma de Anexo.

  Aunque no entraremos en profundidad con los algoritmos matemáticos para no hacer el artículo demasiado técnico, si que es imprescindible un perfecto conocimiento de la generación, intercambio y manejo de las claves, explicado con detalle en le capítulo 3.


  1.2.  El ataque básico.

  Para poder realizar esta técnica, el atacante tiene que capturar y almacenar un determinado flujo de datos en el momento del emparejamiento y autenticación de dos dispositivos BlueTooth. Luego todo consiste en aplicar un algoritmo de fuerza bruta para poder saber el PIN utilizado en el emparejamiento.

  Para hacer uso de esta técnica necesitamos previamente implementar los algoritmos de generación de claves, E₁, E₂₁ y E₂₂, que son una modificación del conocido cifrado por bloques SAPHER+.




  Conocidos gracias al sniffer el BD_ADRR y el IN_RAND, generamos un PIN y aplicamos estos datos a nuestra implementación de E₂₂, con lo que conseguimos una K_init. El atacante puede usar la K_init para desXORear LK_RAND_A y LK_RAND_B (mensajes 2 y 3), y aplicarlas al algoritmo E₂₁ para conseguir una hipotética K_AB.

  Ahora podemos aplicar la K_AB y el AU_RAND_a (mensaje 4) al algoritmo E₁ para conseguir el SRES y compararlo con el SRES del mensaje 5.

  Si coinciden es que ya tenemos el PIN correcto y la Clave de Linkado.
Si fuera necesario se pueden usar el valor de los mensajes 6 y 7 para asegurarnos.




  Si recordamos que SRES es de 32 bits, nos encontramos con el impedimento de que solo tenemos 64 bits (SRES_A y SRES_B) para poder comparar nuestra salida de datos. Esto implica que el sistema solo es efectivo si el PIN es de menos de 64 bits (hasta 7 dígitos). Si el PIN es mayor, hay muchas posibilidades de tener varios candidatos, y aunque el sistema encuentre uno, es posible que no sea el correcto.



  1.3.  Implementaciones del Crack.

  Los autores del método han desarrollado varias implementaciones de los algoritmos, desde la versión sin optimizar hasta versiones con tablas precalculadas.

  A fecha de hoy el código fuente no está liberado, aunque podéis encontrar una descripción completa de los algoritmos en el documento original.

  Como vemos en la siguiente tabla, los tiempos de ruptura son totalmente ridículos.




  1.4.  Forzando un nuevo emparejamiento.

  Hasta aquí la idea no es nueva, y como podemos ver, tiene la tremenda dificultad de que hay que estar “presente” en el mismo momento en el que dos dispositivos son emparejados, y esto solo ocurre una vez, porque la Clave de Linkado una vez creada se almacena, y en las siguientes veces el proceso de emparejamiento no se realiza.

  La novedad de todo esto radica en un nuevo ataque, que fuerza al protocolo de conexión a realizar un nuevo emparejamiento, y ahora ya sí que podemos llevar a acabo todo lo descrito anteriormente.

  Asumimos que los dispositivos ya han sido previamente emparejados antes de establecer la nueva comunicación, con lo cual como hemos dicho se saltan el proceso de creación de K_AB y pasan directamente a la Autenticación.

  Hay descritos tres métodos para forzar un nuevo emparejamiento, y su eficacia depende del firmware de los dispositivos.

     1.- Dado que los dispositivos pasan directamente al proceso de autenticación, el dispositivo maestro envía al esclavo un mensaje AU_RAND, y queda a la espera del SRES de retorno. Las especificaciones BlueTooth contemplan la posibilidad de que un dispositivo pierda su Clave de Linkado, y en ese caso, el esclavo manda un mensaje LMP_not_accepted como respuesta.
De esta forma, justo después de que el maestro haya enviado el AU_RAND, el atacante inyecta un mensaje LMP_not_accepted hacia el maestro, forzándole a descartar su Clave de Linkado y a reiniciar un nuevo emparejamiento.





    2.- Al comienzo de la fase de Autenticación, el dispositivo maestro tiene que enviar un mensaje AU_RAND al dispositivo esclavo. Si antes de que haga esto, el atacante envia un mensaje IN_RAND hacia el dispositivo esclavo, este creerá que el maestro ha perdido su Clave de Linkado, y forzará un nuevo emparejamiento.




    3.- Como hemos visto antes, durante la fase de Autenticación, el dispositivo maestro envía un mensaje AU_RAND al esclavo y queda a la espera de un SRES de respuesta. Si después de que el maestro haya enviado el AU_RAND, el atacante le inyecta un SRES aleatorio, forzará el reinicio de la fase de Autenticación. Después de cierto número de intentos, el maestro da como errónea la Autenticación, y forzará un nuevo emparejamiento.




  Si quisiéramos hacer un ataque “on line”, la forma es grabar toda la transferencia entre los dispositivos después del proceso de emparejamiento. Mientras tanto vamos crackeando el PIN (0.06 – 0.3 seg para un PIN de 4 dígitos), descodificados toda la información guardada y seguimos descodificando “on line”.
Dado que BlueTooth transfiere a 1 Megabit/s, con un buffer de 40KB es suficiente para un PIN de 4 dígitos.

  Suponiendo que tengamos el software necesario, aún así no es tan fácil el ataque.

  El re-emparejamiento es un ataque activo, y requiere inyectar datos en un momento determinado, con lo que necesitaremos un dispositivo BlueTooth “preparado” para poder llevar acabo las inyecciones en su momento preciso, ya que normalmente esto no nos será posible.

  Si el dispositivo esclavo verifica la BD_ADDR del maestro, necesitaremos poder spoofear la BD_ADDR, que también requiere un dispositivo BlueTooth “preparado”.

  Y por último, si el ataque tiene éxito, los usuarios tienen que meter de nuevo el PIN, lo que puede levantar sospechas.

1.  Introducción a BlueTooth.
  1.1.  Propósitos y alcance.
  1.2.  Definiciones.
  1.3.  Referencias.

2.  Especificaciones BlueTooth.
  2.1.  Tecnología.
  2.2.  Pila de protocolos.
  2.3.  Descripción de los protocolos.
    2.3.1  Link Manager y Link Manager Protocol
      2.3.1.1  Link Manager
      2.3.1.2  Modos.
    2.3.2  Interfaz de la Controladora de Máquina (HCI).
    2.3.3  Protocolo de Adaptación y Control de Enlace (L2CAP).
    2.3.4  Protocolo RFCOMM.
    2.3.5  Protocolo de Descubrimiento de Servicios (SDP)
    2.3.6  Perfiles.
      2.3.6.1  Acceso telefónico y PPP a redes.
      2.3.6.2  OBEX Object Push.

3.  Seguridad en BlueTooth
  3.1.  Descripción general.
    3.1.1.  Modos de Seguridad.
    3.1.2.  Emparejamiento de Dispositivos.
    3.1.3.  Inicialización y Generación de claves.
      3.1.3.1  Generación de la Clave de Inicialización.
      3.1.3.2  Generación de la Clave de Linkado.
      3.1.3.3  Autenticación en BlueTooth.
      3.1.3.4  Generación de Clave de Cifrado.
    3.1.4.  Proceso de cifrado.

  3.2.  Debilidades de la seguridad.
    3.2.1.  Generales.
    3.2.2.  Vulnerabilidades del Cifrado.

  3.3.  Vulnerabilidades.
    3.3.1.  Permisos IrMC.
    3.3.2.  Errores de la pila.
    3.3.3.  Servicios ocultos.

  3.4.  Los Comandos AT.
    3.4.1.  Notación de los comandos AT.
    3.4.2.  El juego de comandos AT específico para telefonía móvil GSM
    3.4.3.  Documentación de los comandos AT más interesantes
    3.4.4.  Documentación técnica

  3.5.  Una aplicación práctica de los comandos AT.
    3.5.1.  IrD-Hacking: obteniendo la agenda de un móvil por Infrarrojos.
 
4.  Ataques a BlueTooth.
  4.1.  Ataques de Localización y Enumeración.
    4.1.1.  Modo visible.
    4.1.2.  Modo no visible.
      4.1.2.1.  Fuerza bruta.
    4.1.3.  Enumeración de servicios.
      4.1.3.1.  HCI con HciTool.
      4.1.3.2.  SDP con SdpTool.

  4.2.  Ataques BlueBug con comandos AT.
    4.2.1.  Escenario 1. Desde Pocket PC.
      4.2.1.1  Hardware.
      4.2.1.2  Software.
      4.2.1.3  Interfaz de la aplicación.
      4.2.1.4  Características técnicas de la plataforma comprometida.
      4.2.1.5  Descripción del Ataque.
        4.2.1.5.1  Estableciendo la comunicación.
        4.2.1.5.2  Abriendo la aplicación.
        4.2.1.5.3  Configurando el ataque.
        4.2.1.5.4  Iniciando el ataque.
        4.2.1.5.5  Recibiendo respuestas.
        4.2.1.5.6  Extrayendo la agenda de contactos.
      4.2.1.6  Sobre el software utilizado.

    4.2.2 Escenario 2. Desde PC.
      4.2.2.1 Requisitos previos.
      4.2.2.2 Obtener los canales de transmisión.
      4.2.2.3 Comandos AT.
      4.2.2.4 Enlazar Rfcomm por canal 1.
      4.2.2.5 Conectar a Rfcomm
      4.2.2.6 Obtener información básica.
      4.2.2.7 Obtener Imei
      4.2.2.8 Iniciar llamada desde el dispositivo víctima.
      4.2.2.9 Otros comandos AT.


  4.3.  Ataques de Denegación de Servicio.
    4.3.1.  DoS  por Mensaje OBEX en Nokia 6310i

  4.4.  Ataques de autenticación.
    4.4.1.  Suplantación por inserción de datos.
    4.4.2.  Blue Snarfing.
    4.4.3.  BlueBug
    4.4.4.  Hacking desde el movil.
      4.4.4.1.  Blooover.
      4.4.4.2.  BlueTooner

  4.5.  Otros.
    4.5.1.  Bluejacking.
    4.5.2.  Ataque por fuerza bruta
    4.5.3.  Ataque de emparejamiento.
    4.5.4.  Escanéo de PSM
    4.5.5.  Ataque de reflacción.
    4.5.6.  Ataque Man in the Middle
    4.5.7.  Crackeo del PIN on-line.
    4.5.8.  Crackeo del PIN off-line.
    4.5.9.  Robo físico de clave de enlace.

1.  Introducción.

El concepto de Bluetooth surge de la imperiosa necesidad de las grandes empresas de telecomunicaciones e informática, de desarrollar una interfaz abierta, que facilite la comunicación entre los diferentes equipos informáticos y telefónicos, aprovechando la capacidad y la movilidad de los dispositivos inalámbricos, para la total supresión de los cables de conexión, adoptando así un único estándar de conexión.

El Bluetooth Special Interest Group (SIG), una asociación comercial formada por líderes en telecomunicación, informática e industrias de red, es la encargada del desarrollo e introducción en el mercado de esta tecnología inalámbrica.

Los promotores de Bluetooth incluyen Agere, Ericsson, IBM, Intel, Microsoft, Motorola, Nokia y Toshiba, y centenares de compañías asociadas.

El nombre viene de Harald Bluetooth, un Vikingo y rey de Dinamarca a de los años 940 a 981, fue reconocido por su capacidad de ayudar a la gente a comunicarse. Durante su reinado unió Dinamarca y Noruega.

  1.1.  Propósito y alcance
  El propósito de este taller es introducirnos en los aspectos de la seguridad de BlueTooth y en los ataques existentes que rompen esa seguridad.

  1.2.  Definiciones.
    •  SIG: Special Interest Group. La organización propietaria de la marca comercial BlueTooth, y la responsable del desarrollo y evolución de esta tecnología.

  1.3.  Referencias.

Cualquiera que tenga el mínimo interés en sistemas de cifrado de clave pública/privada, como PGP, se habrá preguntado alguna vez que por qué son necesarios números primos muy grandes, o que cuantas parejas de claves salen de dos de esos números primos, o que como será el sistema
para que lo que se cifra con una clave se descifre solo con la otra, o que por qué es tan dificil obtener la clave privada a partir de la pública, etc.

Si alguno además se ha preocupado de leer lo que hay publicado por ahí, y no es matemático, supongo que lo habrá dado por imposible con tanto phi, numeros primos relativos, modulos, etc.

El propósito de este artículo es explicar como va esto de la manera más fácil posible, empezando desde cero y pasito a pasito.

Así veremos que no es tan difícil como parece.



Artimética modular:

Aunque el nombre asuste, es bien sencillo. Supongamos que nos ponemos a sumar o restar horas, en un reloj de esfera de 12 horas, nada de digitales. Si son las 8 y le sumamos 6 horas, nos quedan las 2. O sea, cuando pasamos de 12 empezamos por el 1.

Pues eso es aritmética modular. En este caso sería módulo 12.
Así podemos decir que 8 + 6 mod 12 = 2

La única diferencia es que en la aritmética modular incluimos el cero. Entonces en nuestro caso del reloj los números que existirían serían del 0 al 11. No habría por ejemplo el 12, porque "daría la vuelta" y pasaría a ser cero, o el 13 que pasaría a ser 1. Solo existen esos números.

Ahora en módulo 7. Nuestro universo de números sería {0,1,2,3,4,5,6}.
Si hiceramos 3*5, en los número reales sería 15, pero en módulo 7 serían 2 vueltas (7+7) y uno mas. O sea, 3*5 mod 7 = 1.

Como vemos, en realidad lo que hacemos para calcular el módulo es dividir 15 entre 7 y quedarnos con el resto, que es 1.
De esta misma forma, si dividimos 64 entre 7, nos sigue quedando que el resto es 1 (lo único que hemos hecho es "darle mas vueltas" al reloj), así que podemos decir que 64 = k*7 + 1. K nos da igual porque es el número de vueltas que le vamos a dar al reloj.

De forma genérica, si un número a (el 64) mod n (el 7) = resto (el 1), a = k*n + resto.

Bien, ahora vamos a fijarnos en este mismo ejemplo. Vemos que en mod 7, 3*5 = 1. Al igual que con los números reales, si dos números se multiplican y dan 1, es que son inversos (5 * 1/5 = 1).

Así podemos decir que 3 y 5 son inversos en módulo 7.

Hasta aquí claro? Es fácil verdad?


Seguimos,
Hay una propiedad, que os la teneis que creer, que dice que un número a tiene inversa módulo n, si no existe ningún número (excepto 1) menor que a y menor que n que los divida de forma exacta.
Esto es a lo que se llama primos relativos. 8 y 5 serían primos relativos, porque no hay ningún número que los divida, aunque 8 no sea primo. Su máximo común divisor es 1.

En el ejemplo del módulo 7, vemos que todos los números (el cero no cuenta) tienen que tener inversa, porque 7 es primo absoluto y no va a existir ningún número que lo divida.

* La inversa del 1 es el 1:  1 * 1 = 1 que dividido entre 7 es igual a cero y resto 1, (1*1 mod 7 =1)
* La inversa del 2 es el 4:  2 * 4 = 8 que dividido entre 7 es igual a 1 y de resto 0, (2*4 mod 7 = 1)
 etc...



Esto también es fácil no?
Vale, vamos a entrar ahora con el temido número phi.

El número phi nos dice la cantidad de números que tienen inversa para un módulo.

Me explico, en nuestro caso, vemos que en el módulo 7 todo su conjunto de números, menos el cero, tienen inversa, porque 7 es un número primo y nos lo dice la propiedad anterior. O sea, hay 6 números (del 1 al 6) que tienen inversa, y si phi(7) nos dice la cantidad de números que tienen inversa, queda que phi(7) = 6.

De forma genérica, si n es un número primo, phi(n) = n - 1. (El menos 1 es porque no contamos con cero).

Por la misma razón, si n está formado por la multiplicación de dos números primos, n = p * q, entonces phi(n) = (p-1) * (q-1).


Generación de claves.

Ahora entramos ya en el meollo del artículo.
Para la generación de las claves pública y privadas, vamos a basarnos en phi(n).

Ahora creeros el por qué se hace esto, que luego lo entendereis.

Lo que hacemos es coger dos números primos muy muy grandes, que serán el p y q de antes, y multiplicarlos para calcular n.
Vale, ya tenemos n, lo dejamos apartado a un lado.

Calculamos el phi(n) que es (p-1)*(q-1).
Vale ya tenemos por otro lado phi(n).

Y ahora escogemos las claves.
La clave pública será un número aleatorio que sea primo relativo con phi(n). Esto es para que tenga inversa, recordad que si no hay ningún número menor que los divida es que tiene inversa. A ese númerro le llamamos e y la clave pública será la pareja (e,n).
A la inversa le llamamos d, y será la clave privada.

En este momento tenemos un número e, que sale de phi(n), un número d, que sale de phi(n) y el módulo n. Como ahora veremos, con e y n podemos cifrar y con d y n podemos descifrar, con lo que podemos tirar phi(n) a la basura.

Así que tiramos phi(n), que es el generador de nuestras claves.
Si alguien quisiera generar nuestra clave privada de nuevo, tendría que recuperar phi(n), no?

Y aquí está una de las cosas que siempre oimos, lo de la imposibilidad de factorizar.
El que quiera recuperar phi(n) para sacar la clave privada calculando la inversa de la pública, solo conoce n, no conoce p ni q. Así que tendría que empezar a dividir n entre números primos gigantes para adivinar p y q y luego poder hacer el (p-1)*(q-1) que es phi(n).
Y aquí hay dos dificultades, una es que ir dividiendo requiere muchos recursos, y otra es que saber si el número por el que divide es primo, por lo que la factorización de n (que así se llama a encontrar p y q) se vuelve un problema intratable.

Cifrar y descifrar.
1- Para cifrar, lo único que hacemos es elevar lo que queremos cifrar a e (el exponente de la clave pública).

2- Para descifrar es un poco más complicado.

Como hemos visto, las claves vienen calculadas en módulo phi(n), y nada tienen que ver a priori con n, son dos "segmentos" de números distintos.

Entonces como lo hacemos?

Hay una propiedad que dice que si multiplicamos un número a (distinto de cero) por si mismo phi(n) veces, o sea, a^phi(n), el resultado nos da 1 en módulo n.

En el ejemplo del módulo 7, donde phi(7) = 6, si multiplicamos por ejemplo el 2 por si mismo 6 veces (2^6) nos da 64 que como vimos 64 mod 7 = 1.

En esta propiedad es la que se basa todo el algoritmo RSA.



Vamos a calcular m^e (cifrar m) y luego elevarlo a d (descifralo) para ver si nos sigue quedando m.

Lo hacemos paso a paso.
* Elevar m a e y luego a d (m^(e^d)) es lo mismo que hacer m^(e*d). se multiplican los exponentes.
* D y e vienen de phi(n), y son inversas, o sea que d*e mod phi(n) = 1
* Según vimos al principio, d*e mod phi(n) = 1 es lo mismo que decir que d*e = k*phi(n) + 1.
* Resumiendo, tenemos que elevar m a phi(n), el resultado elevarlo a k y todo ello multiplicarlo luego por m otra vez. Recordad que es m elevado a k*phi(n) + 1, si aplicamos las reglas de la matemática normal podemos hacer (m^phi(n))^k * (m^1).
* Y hasta aquí hemos llegado en principio, como podemos ver, tenemos en medio a phi(n), el cual desconocemos porque lo hemos tirado al generar las claves, y sin conocerlo no podremos seguir, y no vamos a factorizar n claro. Pero entonces hacemos caso de la última propiedad, que nos permite poner phi(n) en factor de n.
* Si elevamos m a phi(n) nos da que m mod n = 1. Por lo cual sustituimos en la anterior fórmula y nos quedaría (1^k)(m^1) = m

Con lo que vemos como podemos descifrar mediante claves generadas por un módulo (phi(n)) usando otro módulo distinto, n.

Ejemplo real.

- Por un lado tenemos que n = 5 * 11.
- Y por otro lado tenemos que phi(n) = 4 * 10 = 40
- Elegimos e=7 que es primo relativo con 40.
- Calculamos su inversa módulo 40, que es 23. 7*23 = 161 = 1 mod 40. Tenemos que d = 23

Tenemos que la clave pública es (55, 7) y la privada (55, 23).

Si queremos cifrar el número 2, bastará con calcular 2^7 = 128 = 18 mod 55.
Si queremos descifrar, elevamos 18 a 23 módulo 55 y nos da 2.


Bueno, esto es todo.
Si lo leeis por encima os parecera dificil, pero si le dedicais algo de tiempo vereis lo sencillo que es.

Tened en cuenta que probablemente no haya otro documento donde se explique tan "lento", y si lo hay yo no lo he encontrado después de buscar mucho tiempo. Además estoy seguro de que muy poca gente lo entiende de forma tan clara a como aquí está espuesto, y eso es un privilegio del que ahora disponeis, así que aprovechadlo, porque es mi último artículo de criptografía en el foro.

Salu2

Postead vuestras dudas aquí, y poco a poco lo iremos acalrando más si cabe.

Cifrado WEP (Wireless Equivalent Privacy).

Es un mecanismo de cifrado de datos utilizado por el protocolo de comunicación WiFi.
Tras este pretencioso nombre se esconde en realidad el algoritmo de cifrado de clave simétrica RC4.

RC4

RC4 es un algoritmo de cifrado de flujo. Los cifrados de flujo funcionan expandiendo una clave secreta (en el caso de WEP, una vector de inicialización(IV) público y una clave secreta) en una clave arbitrariamente larga de bits pseudo aleatorios (el keystream).

El cifrado se lleva a efecto aplicando or-exclusivos al texto plano P antes de enviarlo.
Simbólicamente, este proceso puede ser representado así:
A -> B: v,(P (+) RC4(iv, k));

El descifrado consiste sencillamente en invertir el proceso. Generar un keystream idéntico basado en la IV compartida y en la clave secreta, para después aplicar de nuevo la función XOR sobre el texto cifrado.

Además entran en juego unas sumas de chequeo que comprueban que el mensaje no ha sido alterado por el camino.

Como veremos con detalle, WEP adolece de varias vulnerabilidades severas de seguridad.

Estas vulnerabilidades dan lugar a cierto número de ataques, tanto activos como pasivos, que permiten escuchar y alterar conexiones inalámbricas.

Análisis seguridad WEP.

Como se demostró hace un par de años, el algoritmo RC4 sufre múltiples vulnerabilidades, entre las cuáles destacan las que permiten reducir la longitud efectiva del cifrado a 24 bits, en lugar de los 128 que se pueden definir como máximo en WEP.
 
Nótese que un cifrado de 64 no es la mitad de débil que uno de 128, sería uno de  127 bits.
2^128 / 2^1 = 2^ (128-1) = 2^127, con lo que uno de 24 es la mitad de la mitad de la mitad …etc de débil que uno de 128.

Reutilización del KeyStream.

Una debilidad bien conocida de los algoritmos de cifrado de flujo es que cifrando dos mensajes (P1, P2) con la misma clave (k) y vector IV se puede revelar información sobre ambos mensajes:

Si          C1 = P1 (+) RC4(iv, k)
y           C2 = P2 (+) RC4(iv, k)

entonces

     C1 (+) C2 = (P1 (+) RC4(iv, k)) (+) (P2 (+) RC4(iv, k)) = P1 (+) P2

En otras palabras, aplicando XOR a los dos textos cifrados (C1 y C2) el keystream se cancela, y el resultado que obtenemos es el XOR de ambos textos planos (P1 (+) P2).

Esto nos brinda las siguientes posibilidades.

•Conocido el texto plano de uno de los mensajes, dispondremos inmediatamente del otro texto plano.

•Podremos recuperar P1 y P2 teniendo sólo P1 (+) P2, debido a la redundancia que habitualmente tienen los textos planos. Podemos buscar dos textos sobre los que, aplicados un XOR, resulten en el valor dado P1 (+) P2.

Disponiendo de n textos cifrados con el mismo keystream tendremos lo que comúnmente se denomina un problema de profundidad n. Descifrar el tráfico se facilita en tanto en cuando n aumente, ya que el resultado del XOR de cada par de textos planos puede ser calculado, y se conocen varias técnicas clásicas para resolver esta clase de problemas (análisis de frecuencias, etc).

Como vemos para que estos ataques tengan éxito necesitamos disponer de textos cifrados en los que alguna porción del keystream se haya utilizado más de una vez, y de un conocimiento parcial de parte del texto plano.

Para prevenir estos ataques, WEP utiliza un IV diferente por cada paquete transmitido, de este modo, cada paquete recibe un keystream diferente.

El problema es que el vector IV se incluye en la parte no cifrada de la transmisión, para que luego el receptor pueda descifrarlo, y está por tanto disponible también para los agresores, aunque la clave secreta siga siendo desconocida y mantenga la seguridad del keystream.
Una gestión inadecuada del vector IV, que implique su reutilización, provoca como consecuencia una reutilización de la clave keystream, puesto que generalmente la clave secreta compartida k no cambia.

Ya que los IVs son públicos, el duplicado de IVs puede ser fácilmente detectado por los posibles agresores.
Nos referiremos a estas reiteraciones de valores IV como colisiones.

El estándar WEP recomienda (pero no requiere) que IV cambie en cada paquete.
Sin embargo, no dice nada acerca de los mecanismos aconsejables para seleccionar IVs y, por esta razón, algunas implementaciones del sistema lo hacen precariamente.

Hay un gran número de las tarjetas PCMCIA que reestablecen IV a 0 cada vez que son reiniciadas, e incrementan IV en uno en cada paquete posterior.
Estas tarjetas se reinician automáticamente cada vez que se introducen en un portátil, algo que se espera pase a menudo.

En consecuencia, los keystream correspondientes a IVs de valor bajo son susceptibles de ser reutilizados muchas veces durante el tiempo de vida de la clave privada.

Peor aún, el vector IV utilizado en WEP tiene una longitud predefinida de tan sólo 24 bits, está prácticamente garantizando que se usará un mismo IV en múltiples mensajes.

Un cálculo rápido muestra que un punto de acceso ocupado que transmita paquetes de 1500 bytes a una media de 5Mbps de ancho de banda (la velocidad máxima correpondería a 11Mbs) agotará todos los valores posibles de IV en menos de doce horas.

Incluso en instalaciones con menor ocupación de canal, un agresor paciente puede encontrar duplicados fácilmente.

Hay otros detalles de implementación pueden provocar iteraciones del keystream más frecuentemente.
Una implementación que utilizase un IV aleatorio para cada paquete produciría una colisión cada 5000 paquetes aproximadamente, que se resumen en tan sólo varios minutos de transmisión.

Pero lo peor de todo es que el estándar 802.11 no exige que IV cambie en cada paquete, lo que podría permitir el uso de un IV idéntico en todos los paquetes sin que ello suponga una disconformidad con la norma estándar.

Explotando la reutilización del keystream.
 
Una vez localizados dos paquetes con el mismo IV se pueden aplicar varios métodos para recuperar el texto plano.

•Conocido el texto en plano de uno de los mensajes es muy sencillo acceder a los contenidos del otro.
Hay muchas formas de obtener candidatos plausibles de texto plano.
Muchos campos del tráfico IP son predecibles, ya que los protocolos utilizados usan estructuras de mensaje perfectamente conocidas.
Por ejemplo, las secuencias de entrada a sistemas son bastante uniformes para la mayor parte de los usuarios, y también lo son los contenidos (la palabra Password: como mensaje de bienvenida), que pueden ser utilizados para ataques a la clave.

•Otro ejemplo podría consistir en la posibilidad de reconocer por análisis de tramas de tráfico y longitud una librería compartida que estuviese siendo transferida en un sistema de red. Esto suministraría una gran cantidad de texto plano conocido que permitiría su utilización para realizar un ataque al keystream por reutilización.

•Es posible provocar la transmisión de textos planos conocidos enviandolos directamente al terminal móvil desde un ordenador conectado a internet en manos del agresor.

•El agresor también puede enviar correo electrónico a usuarios y esperar que lo descarguen por medio del enlace inalámbrico. Enviar correo no solicitado (spam, en argot) puede ser un buen método para hacer esto sin levantar sospechas.

A veces obtener texto plano conocido puede ser incluso más sencillo. Un punto de acceso que probamos emitía paquetes broadcast de modo cifrado y no cifrado cuando la opción de controlar el acceso a la red estaba desactivada. En este caso, un agresor con una tarjeta 802.11 puede transmitir broadcasts al punto de acceso (que serán aceptados, porque el control de acceso está desactivado) y observar su forma cifrada durante la retransmisión. Es inevitable que esto suceda en una subred que contiene una mezcla de clientes WEP con otros sin soporte para cifrado, ya que los paquetes broadcast deben llegar a todos y cada uno de los clientes; no hay forma de evitar esta técnica para recoger texto plano conocido.

En definitiva, incluso sin conocer ningún texto plano es posible analizar, por medio de suposiciones, posibles textos planos susceptibles de ser transmitidos que puedan desembocar en la obtención del la clave privada.

Diccionarios de descifrado.

Una vez que se obtiene el texto plano de un mensaje se puede aislar el valor del keystream, ya sea por análisis de IVs o por otros métodos.
Es posible usar este keystream para descifrar cualquier otra trama que utilice un mismo IV.

Dado que las claves secretas compartidas k son cambiadas ocasionalmente, el agresor, acumulando datos, puede construir una tabla de keystreams que correspondan a distintas IV.
Una vez que se tiene la tabla, es posible descifrar inmediatamente cada texto cifrado con muy poco esfuerzo.

Esto es independiente de la longitud de la clave de cifrado, ya que el tamaño del diccionario depende del tamaño de IV, que está prefijado en 24 bits.

Es más, el diccionario del agresor puede hacerse más práctico aprovechando el comportamiento de las tarjetas PCMCIA que ponen el vector IV a 0 cada vez que son reiniciadas.
Puesto que en los casos más comunes las tarjetas son iniciadas al menos una vez al día, el agresor puede limitarse a construir un diccionario centrado sólo en los primeros miles de IVs, lo que le permitirá descifrar la mayoría de los paquetes que circulen a través del punto de acceso.
En una red con numerosos clientes 802.11 las colisiones en los primeros miles de IV’s serán abundantes.

Gestión de claves
El estándar 802.11 no especifica cómo llevar a cabo la distribución de claves.
Depende de un mecanismo externo para poblar la matriz de cuatro claves compartida globalmente.
Cada mensaje contiene un campo identificador de clave especificando el índice de la matriz que se utiliza para el cifrado.

El estándar también permite asociar una clave específica de la matriz para cada estación móvil; sin embargo, está práctica no es habitual. La mayoría de las instalaciones usan una única clave para la toda red.

Esto perjudica severamente la seguridad del sistema, ya que las contraseñas están almacenadas en los terminales clientes. Con técnicas de hacking habituales pueden ser robadas fácilmente.

La reutilización de una clave única por muchos usuarios ayuda también a convertir los ataques en algo más práctico, porque aumenta la posibilidad de colisión de IVs.
La posibilidad de una colisión casual aumenta proporcionalmente con número de usuarios, y si además tenemos en cuenta que las tarjetas PCMCIA establecen a 0 el vector IV cada vez que son reiniciadas todos los usuarios reutilizarán keystreams correspondientes a un pequeño rango de IVs.
El hecho de que muchos usuarios compartan las mismas claves también significa que es difícil sustituir esta información, porque resulta comprometido ponerla en boca de todos.
Además esto no será habitual puesto que cambiar una clave requiere que todos y cada uno de los usuarios reconfiguren su adaptador inalámbrico.

En la práctica estimamos que puedan pasar meses, o incluso más tiempo, antes de que se cambien las claves privadas, lo que permite al potencial agresor disponer de una generosa cantidad de tiempo para buscar instancias de reutilización de keystreams.


En próximos post analizaremos otras técnicas como la modificación o inyección de paquetes, ataques man in the middle, de reacción, etc.

Salu2.

Estimados todos,

Creo, y estoy convencido, de que el futuro (ya presente) de la seguridad tele/informática va a venir si no lo es ya de la criptografía.

Es un campo muy interesante, cifrados simétricos, asimétricos, mixtos, estandar x.509, firma electrónica, certificados, vulnerabilidades en cifrados wifi, blutooth, tiempos de ruptura, algoritmos, etc.

Aplicando esta tecnología correctamente (y no limitándose solo a la transferencia, como se hace hasta ahora, podeis ver un ejemplo práctico en http://www.seguridad0.com/index.php?b3ef09e4789cddce67cb4627adf90c54&tim=27-11-2004&ID=1003), se puede alcanzar un nivel de seguridad del 100% (dependiendo exclusivamente el porcentaje del grado de imbecilidad del usuario).

Me gustaría proponer un apartado específico para esta temática, que en serio, da mucho más juego del que imaginais, y va a ser imprescindible para toda la gente aficionada y profesional de la seguridad (incluso en leyes, adaptación ley SOX, LOPD, etc).

Mi tiempo es limitado, supongo que como el de todos, pero si el impedimento va a ser falta de moderadores en esta temática, estoy dispuesto a presentarle mis credenciales a quien corresponda, y que evalue si mi preparación es la suficiente. Si lo es me comprometo a alimentar el foro con contenidos de alto nivel y a responder a todas las dudas en las que esté capacitado (siempre dentro de mis posibilidades, no soy Dios ).

Bueno, yo lanzo el guante con toda mi buena fé, y quedo a vuestra disposición.

Gracias y un saludo a todos.