ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.
Ataques y Vulnerabilidades contra la Criptografía
Para acabar con el tema de Encriptación y Autentificación, es obligado mostrar sus vulnerabilidades. Es cierto que muchos de los ataques y vulnerabilidades de la criptografía son simplemente teóricos, se conocen que son efectivos pero no es posible llevarlos a cabo por una u otra razón. No obstante, es una búsqueda constante. En el mundo existen increíbles criptólogos con una formación en matemáticas y en la creación de algoritmos seguros sin igual. Pero como todo en esta vida nada, y repito nada, está exento de posibles ropturas.
En realidad esto es importantísimo, tanto las mentes que son capaces de diseñar algoritmos como los que tenemos como aquellos que pasan horas y horas intentando lograr un ataque exitoso contra un sistema criptográfico. Porque así es la única forma real de poder construir sistemas seguros. Si nadie se dedica a estudiar estos sistemas, es posible que diversos atacantes puedan disponer de herramientas y materiales para poder llevar a cabo un acceso no autorizado a un sistema o la interceptación y descifrado de cualquier mensaje. En cambio, cuando tienes a muchísimas personas que trabajan incluso para ello, para lograr fallos de seguridad en estos sistemas, estos mismos intentos te están garantizando que el sistema es seguro, puesto que aun no se han logrado romper. No hay que olvidar por supuesto los numerosos concursos anuales de criptografía, en los que se están desafiando constantemente a organizaciones y particulares a resolver un problema dado, por ejemplo revertir un cifrado asimétrico o simétrico, revertir un Hash…
Por suerte y por desgracia, no son pocas las herramientas, método o sistemas que existen actualmente para poner en jaque la seguridad de todos los sistemas actuales. Suerte porque permite mejorar los sistemas, desgracia porque estos métodos son usados continuamente por hackers y otros para violar un sistema. Vamos a ver algunos de ellos. Podemos decir que prácticamente cualquier método “seguro” tiene un posible ataque que puede aplicarse para romper dicho sistemas:
- Colisiones y preimagen
- Rainbow Tables
- Brute Force Y Diccionarios
- Criptoanálisis
- Ataques Side Channel
El término “Criptoanálisis”, dependiendo de la bibliografía a la que se acuda, puede ser interpretado como un término genérico que englobaría prácticamente a todos los sistemas de ataques contra la criptografía. No obstante, nosotros lo entenderemos como un conjunto de técnicas basadas en el análisis puro y duro de ciertos aspectos del cifrado para poder romperlo.
El término estrella aquí es ¿Qué es un ataque? ¿Qué se considera romper un sistema criptográfico?
Esto se dejó ver en otros capítulos. Un ataque es cualquier intento que tenga como objetivo romper un sistema criptográfico, entendiendo con “roptura” no solamente la obtención de la clave de dicho cifrado o de invertir un hash o… Una roptura criptográfica es un concepto amplio, en el que evidentemente el mejor de los casos e ideal pasa por lograr obtener la clave en caso de un cifrado simétrico o asimétrico, pero como hemos dicho, no solo se interpreta una roptura por ello. Una roptura criptográfica podría implicar:
- Obtención de la clave simétrica (en caso de un cifrado simétrico)
- Obtención de la clave pública (en caso de un cifrado asimétrico)
- Obtención completa o parcial del mensaje original a partir de un mensaje cifrado sin necesidad de la clave.
- Encontrar algoritmos capaz de rebajar en X magnitudes la probabilidad de tener éxito con fuerza bruta o colisiones.
- Una colisión en un Hash.
- Encontrar algoritmos capaz de rebajar en X magnitudes la capacidad de cálculo necesaria para poder solucionar las “matemáticas imposibles”
- etc…
Esto implica que una roptura puede verse como tal desde un punto de vista práctico o teórico. Así por ejemplo si se encontrase una forma de romper AES-128 en 2100 Operaciones en vez de 2128 , constituiría una roptura desde el punto de vista teórico, pero no desde un punto de vista práctico, puesto que aun así sería “imposible” realizar un ataque para obtener una key en un tiempo razonable. Visto esto podemos comenzar a ver algunos de los ataques más usuales, algunos de los cuales ya se han visto por encima.
Colisiones y Preimage
El concepto de Colisiones fue tratado en parte en el capítulo sobre Hash. Un Hash criptográfico pretende ser una función de un único sentido, siendo por tanto imposible a priori invertirlo. Un hash por otro lado funciona como un sistema de “compresión”, dado que para cualquier tamaño de datos de entrada, la salida siempre se mantendrá con una longitud fija. Por definición propia, si la longitud del Hash es fija existirán infinitos mensajes que puedan resultar en un mismo hash. Simplemente conociendo la longitud del hash, podemos conocer a priori el número de mensajes máximos que podrán emitirse antes de que un mensaje produzca un hash repetido. Esto es una Colisión. Los Hash criptográficos intentan no obstante la imposibilidad de poder crear dos mensajes diferentes que compartan el mismo hash ó crear un mensaje diferente a otro para que compartan el mismo hash. Pero como hemos dicho, se tienen en cuenta a la hora de crear los hash para que en la práctica no sea posible, dado que en la teoría simplemente por estadística esto no es así.
Así mismo, también hablamos del problema que entrañaba la paradoja del cumpleaños, la cual hace posible que existan colisiones entre dos mensajes cuales quiera a una razón mucho menor al número total de mensajes posibles. Es decir, la probabilidad de que un mensaje coincida con otro para MD5, el cual es un hash de 128 bits, sería 1 entre 2128. No obstante, la posibilidad de que dos mensajes cualesquiera puedan producir una colisión, simplemente por la paradoja del cumpleaños, se debe de calcular.
Estadísticamente, tomados X elementos de un todo Y en el cual esos X elementos pueden ser repetidos, se tiene que para la probabilidad P, existen dos elementos de X que son él mismo, según la fórmula:
X(P,Y)= Raiz (2Y Ln (1/1-P))
MD5 = 128 bits = Y
P = 99% = 0.99 = > Nunca se puede garantizar una probabilidad del 100%
X(99%, 2128) = Raiz ( 2129 Ln (100))= Raiz (2129 * 4.6) = 265 Aproximadamente.
Pero la paradoja del cumpleaños tan solo es un reto más al que tienen que enfrentarse cualquier Hash criptográfico. Al margen de este tipo de análisis estadístico, se suele atacar al algoritmo propio, logrando en muchos casos unas reducciones increíbles en la posibilidad de encontrar una Colisión. Por suerte o desgracia, para MD5 “recientemente” se logró reducir el índice de colisión a tan solo 210. Y este índice si deja de ser un índice teórico y pasa a ser una aplicación práctica.
¿Pero que importancia tiene esto?
Si recordamos, la firma digital no es más que el cifrado asimétrico del hash del propio mensaje/certificado…. Si se produjese cualquier cambio en dicho mensaje, al comprobarse la firma el hash no coincidiría, el mensaje sería rechazado. ¿Pero que sucedería si pudiésemos construir dos mensajes diferentes que produjesen el mismo hash?. Podría malignamente enviar un mensaje A al usuario X, y esperar que este me firmase el contenido. Dado que dispongo de un mensaje B (completamente diferente a A) que satisface al mismo Hash, podría copiar la firma del mensaje A y plasmarla en mi mensaje B. Ahora podría usar mi mensaje B como si hubiese sido firmado por el usuario X.
Similarmente, es posible intentar vulnerar un hash por medio de un ataque conocido como “preimage” (preimpagen). Mientras que las colisiones buscan encontrar dos mensajes cuales que produzcan el mismo Hash, una preimagen lo que busca es encontrar un hash o un mensaje concreto. Asi, si se de lo que se pretende es de encontrar un mensaje X que satisfaga un Hash dado estaríamos ante un “Primer Ataque de Preimagen” (Se denomina así). No obstante, si lo que se quiere lograr es encontrar un segundo menseje Y (diferente a X) que satisfaga el hash del mensaje X, estaríamos ante un ataque conocido como “Segundo Ataque de Preimagen“.
En la actualidad no existe ningún ataque de preimagen factible a ningún Hash. Así por ejemplo, el Hash MD4 (128 bits) posee un ataque de preimagen que puede llevarse a cabo en 264, pero aun así, 264 no es computacionalmente factible, teniendo en cuenta que MD4 está prácticamente en desuso. Si es computacionalmente posible realizarlo de cara a que puede ser posible llevarlo a cabo, pero de ninguna manera en un entorno real.
Tanto las Colisiones como los ataques de preimagen, suponen un riesgo continuo a los hash criptográficos. Es la razón por la que los viejos Hash van dejando paso a los nuevos Hash. MD2, MD4… MD5 ya ha comenzado a dejarse de usar en muchos lugares, imponiéndose de forma mayoritaria SHA-1, para el cual lo mejro que se ha logrado es una colisión con u índice de 251, siendo poco práctico su aplicación. A todo ello hay que sumarle que pronto estará disponible SHA-3, que sustituirá definitivamente SHA-1 y SHA-2 (este último posee índices de colisión menores que SHA-1)
Rainbow Tables
La idea de las tablas Rainbow es imitar las tablas lookup, es decir, usar espacio en disco para ahorrar tiempo de cálculo. En programación, las tablas lookup son una herramienta fundamental para agilizar muchísimas tareas que de otro modo consumirían muchísimo tiempo de ejecución de un programa. A groso modos, son tablas precalculadas que serán usadas posteriormente, sin que sea necesario realizar el cálculo que llevó el crearlas. El ejemplo más simple quizás sea en de las operaciones trigonométricas.
Si tenemos un programa que tenga que calcular en algún momento alguna operación trigonométrica, simplemente podría ser realizada con la función especifica para ella: Sin(X), Cos(Y).. operación que se realiza en tiempo de ejecución por el procesador, y que son operaciones normalmente costosas. Si nuestro programa debe de realizar una operación trigonométrica de forma aislada no importa, pero imaginar que el programa tiene que ejecutar operaciones trigonométricas a matrices inmensas (por poner un ejemplo). El tiempo invertido en calcular constantemente dichas funciones puede ser solventado usando una tabla. Simplemente, en tiempo de programación, el programador creó una tabla con por ejemplo 360 elementos, y a cada uno de ellos le calculó el Coseno. Dicha tabla estática la implementa en su programa como una constante. Si no requiere una precisión mayor a un grado, el programador cada vez que necesita conocer una razón trigonométrica podría simplemente redondear a la unidad más cercana y usar dicho valor como índice de la tabla. Tendría el valor de la razón trigonométrica al instante sin necesidad de calcularlo.
El concepto de una Tabla Rainbow es el mismo. Por tanto, la tabla Rainbow más simple (e idílica) sería precalcular TODOS los posibles Hash de todas las combinaciones posibles de un alfabeto dado de un número de caracteres dados. Es decir, si nuestro alfabeto son tan solo los números 0-9 y se permite una longitud máxima de 5 elementos, la tabla Rainbow contendría el Hash de 1 millón de elementos, desde el 0 hasa el 999.999. De este modo, si se quisiese conocer en cualquier momento el hash de cualquier número comprendido entre 0-999999 sería instantanio, sin necesidad de calcular el Hash de dicho número. Pero en el caso de los Hash la utilidad es doble. La utilidad es dotar a la función Hash de un camino inverso. En nuestro caso, si sabemos que el dato buscado es un número comprendido entre 0-999.999 no tendríamos que realizar 1 millón de operaciones, tan solo realizar una búsqueda en la tabla para encontrar la equivalencia.
El problema de esta tabla Rainbow de ejemplo es que no es útil. en este caso, para 5 elementos y un alfabeto de 10 elementos (0,1,2,3,4,5,6,7,8,9) tendríamos una tabla con un millón de elementos. Si por ejemplo el Hash calculado fuese MD5, sería 128 bits por hash, es decir, el Hash ocuparía 16 Bytes por cada celda del array (de la tabla). En el mejor de los casos (en este caso concreto), podríamos usar el mismo número buscado como índice de la tabla, con lo que no sería necesario otra celda de al menos 4 Bytes. Es decir, en este casi tan simple tendríamos: 1 millón de elementos * 16 Bytes = 15.26MB aprox. Es decir, en este caso tan simple sería necesaria la friolera de 15MB de espacio en disco. Esto es una cantidad irrisoria en los días de hoy, pero también es cierto que los elementos y el alfabeto seleccionado es de lo más trivial. Si pensásemos en un alfabeto comprendido entre 0-9, a-z (sin contar carácteres en mayúscula) y con una longitud de 8 elementos tendríamos la nada despreciable cantidad de 2.821.109.907.456 posibilidades, o lo que es lo mismo, aproximadamente una tabla de 328 TeraBytes. Es evidente que no es factible.
La solución a este problema llega con “Divide y Vencerás”. Se crean tablas muy grandes, pero para salvaguardar tamaños tan extensos se aplican diferentes técnicas que logran reducir el tamaño a costa evidentemente de tener que realizar ciertas operaciones. El problema siempre será el mismo, llegar a un compromiso entre velocidad-espacio en disco. A tablas más grandes, el tiempo necesario para localizar el elemento será menor, a tablas más pequeñas el tiempo empleado será mayor.
Las tablas Rainbow para lograr este compromiso, lo que realizan es aplicar una serie de transformaciones a los datos de entrada, formando una cadena desde estos (el dato de entrada) hasta un dato final. Al finalizar el proceso, la tabla tan solo contiene el elemento inicial y el final de la cadena. Para verificar si un hash se encuentra en la tabla, lo primero que se le realizará a dicho Hash es aplicar la última transformación (de reducción) que se aplicó en la cadena de la tabla hash. El resultado será buscado en los elementos finales de la tabla Hash. Si el elemento se encuentra, se partirá del elemento parejo de la tabla, al cual se le realizarán las transformaciones pertinentes que se aplicaron a la tabla originalmente, hasta encontrar en la cadena el elemento deseado. Si no se encuentra en la tabla al realizar la última transformación, se partirá de la penúltima transformación y posteriormente la última. Al terminar se vuelve a comprar si se encuentra como elemento final. Estas transformaciones se tratan fundamentalmente en partir de un texto plano cualquiera, por ejemplo la cadena “aaaaaa”. A dicha cadena se le calcula el Hash. Al Hash resultado se le aplica una función de reducción que hace que el hash sea transformado en un texto de nuevo (aunque esta función de reducción no es la función inversa del Hash). Al texto obtenido se le calcula de nuevo el hash y así continuamente, según el número de reducciones que se estén aplicando. A más reducciones menor es la tabla necesaria y más tiempo se requiere para generarlas y utilizarlas. Un ejemplo sencillo de como se construiría una tabla hash y cual sería la tabla Hash resultante final:
| Texto Plano | Hash Original | Reducción 1 | Hash 1 | Reducción 2 | Hash 2 | Reducción 3 | Texto Plano | Reducción Final |
| aaaaaa | 0B4E7A0E5FE8 | 0B4E7A | EBC4C39A693E | EBC4C3 | D54E764C3A8A | D54E76 | aaaaaa | D54E76 |
| bbbbbb | 875F26FDB1CE | 875F26 | B0A1E4DDF443 | B0A1E4 | 8B701D6DA922 | 8B701D | bbbbbb | 8B701D |
| Administrador | 2A2E9A581027 | 2A2E9A | BC291090759A | BC2910 | D605381C2106 | D60538 | Administrador | D60538 |
| Contraseña | B489B4014A83 | B489B4 | 6BA499D1C52C | 6BA499 | A996250124DD | A99625 | Contraseña | A99625 |
Las 7 primeras columnas de la tabla serían datos procesados para la creación de la Rainbow table. En este sencillo ejemplo se usarían solo 3 reducciones. Al texto de entrada se le aplica el hash deseado, en el ejemplo un hash MD5 truncado a los 6 primeros bytes. Una vez se ha calculado el hash este es convertido por una función de reducción a “texto plano”, en este caso la función de reducción no es más que tomar del hash los primeros 3 bytes (de ahí lo de divide y vencerás). Una vez finalizada la primera reducción se vuelve a empezar, es decir, se calcula de nuevo el hash al nuevo “texto plano” y otra reducción, después se le calcula el hash y de nuevo otra reducción. En este caso 3 reducciones, y las 3 actúan del mismo modo. La tabla Hash es constituida por tanto tan solo con los registros iniciales (el texto de inicio) y el resultado de la reducción final, formando una tabla tan solo de dos columnas.
Si un usuario quisiese atacar un hash MD5 con el ejemplo anterior, tan solo tendría que llevar a cabo una serie de comprobaciones:
a) Dado el Hash “H” de entrada se le aplica la última función de reducción. En este caso las 3 son iguales -> R (H)
b) Se realiza una búsqueda del resultado obtenido en el apartado anterior en la segunda columna. Llegados a este punto pueden suceder dos cosas. Hay una coincidencia (Saltar al paso E), no hay coincidencia (pasar al paso C)
c) De no obtener resultado, se iran realizando en cada paso una reducción anterior más, con su cálculo de Hash, de este modo, a cada paso se va recorriendo más la tabla hacia atrás. En el peor de los casos, se tendría que aplicar la reducción primera al hash H, calcular el hash a la reducción, volver a reducir, volver a calcular hash y volver a reducir.
d) De no lograr una coincidencia, la tabla rainbow a fallado y el ataque se da por fallido.
e) Si se encuentra la coincidencia, se tomará el elemento de la primera columna y se comenzará a realizar la cadena hasta que se localice la reducción que produce dicho hash. El resultado por tanto será la reducción.
Veamos esto. Imaginar que tenemos el nombre de usuario y contraseña de un usuario en este MD5 inventado, y que dichos hash son:
Usuario (U)= 2A2E9A581027
Contraseña (C)= EBC4C39A693E
2A2E9A581027 -> Red. 3 (U) = 2A2E9A -> Búsqueda en 2º columna de Tabla -> Fracaso
2A2E9A581027 -> Red. 2 (U) = 2A2E9A -> Hash = BC291090759A -> Red. 3 (Hash) = BC2910 -> Búsqueda en tabla -> Fracaso
2A2E9A581027 -> Red. 1 (U) = 2A2E9A -> Hash = BC291090759A -> Red. 2 (Hash) = BC2910 -> Hash = D605381C2106 -> Red. 3 (Hash) = D60538 -> Búsqueda en tabla -> Éxito!
Registro asociado a D60538 = Administrador
Hash (Administrador) = 2A2E9A581027 -> ¿2A2E9A581027 = 2A2E9A581027? -> Usuario (U) = Administrador
EBC4C39A693E -> Red. 3 (C) = EBC4C3 -> Búsqueda en 2º columna de Tabla -> Fracaso
EBC4C39A693E -> Red. 2 (C) = EBC4C3 -> Hash = D54E764C3A8A -> Red. 3 (Hash) = D54E76 -> Búsqueda en tabla -> Éxito!
Registro asociado a D54E76 = aaaaaa
Hash (aaaaaa) = 0B4E7A0E5FE8 -> ¿0B4E7A0E5FE8 = EBC4C39A693E? -> Fracaso
Hash (aaaaaa) = 0B4E7A0E5FE8 -> Red. 1 (Hash) = 0B4E7A -> Hash = EBC4C39A693E -> ¿EBC4C39A693E = EBC4C39A693E? -> Contraseña (C) = 0B4E7A
En este caso, todas las reducciones son iguales, pero esto normalmente no es así, y cada reducción es una función diferente. Si se recorre la tabla hash completa y se realizan todas las iteraciones sin encontrar coincidencia, la tabla Rainbow ha fallado, y con ella el ataque efectuado a dicho hash.
Este sistema es increíblemente efectivo y rápido para ser capaz cualquier atacante a revertir cualquier hash “simple”, de modo que un atacante pueda normalmente obtener el usuario o contraseña que originó dicho hash. No obstante las tablas Rainbow tiene una utilidad relativa. Primero, computar una tabla hash relativamente completa requiere de muchísimo tiempo, es por ello por lo que no es raro encontrar tablas “pequeñas” que cubren tan solo un espacio relativo, por ejemplo una tabla Rainbow que sea capaz de revertir cualquier Hash MD5 con un diccionario de a-z, A-Z de hasta 7 caracteres. Y ya no solo es el tiempo necesario para computarla, sino el espacio en disco. Dado que tanto el espacio para calcular las tablas hash, así como su tamaño en disco depende prácticamente tan solo del tamaño del diccionario, algo que tendría que tener siempre en cuenta el usuario es escoger contraseñas o nombres de usuario de una longitud relativamente larga (al menos 8 caracteres para contraseñas) y usando combinaciones de letras mayúsculas, números y signos. Esto lo comprenderemos mejor en los ataques de fuerza bruta. La idea es que aunque se requiera de un tiempo ingente necesario para precalcular las tablas Rainbow, una vez creadas estas pueden ser reutilizadas una y otra vez. Existen multitud de lugares que venden tablas rainbow ya creadas.
Otra alternativa altamente eficaz, es usar Salt. Esto es algo que ya se comentó en su momento. Salt suele ser un número determinado de bits que se añade al mensaje de entrada para conformar un hash mucho más seguro. De este modo entre otras cosas, hace que las tablas rainbow sesan completamente ineficaces. La única forma sería constituir nuevas tablas rainbow computando todas las alternativas posibles con el Salt. Dado que el Salt puede ser modificado en cualquier momento, las tablas Rainbow tendrían que ser reconstruidas cada vez. Salt suele ser un dato conocido, pero no por que sea conocido implica que el sistema sea menos eficaz. Según lo explicado con anterioridad, si se añadiese un número indeterminado de bits a nuestro mensaje original, este no podría ser revertido por la tabla hash, puesto que jamás se encontraría en ella. Normalmente se usa algo como lo siguiente:
Contraseña: Perico -> Hash (Contraseña) = 5E48C54D938DC613366C1212E5FA7349
Salt: 0A1B2C3D4E5F
Hash Seguro = Hash (Contraseña.Salt) -> Hash Seguro = Hash (Perico.0A1B2C3D4E5F) = 21208C690B7ECCF92518D8055E9B361D
El segundo Hash no sería jamás encontrado en una tabla Rainbow, a menos que se hubiese generado para tal efecto, cosa muy poco probable. Dado que la Salt suele cambiar, lo normal es que el mismo hash es transmitido con la salt, para que se sepa que Salt se ha usado, y se tenga en cuenta a la hora de verificar el usuario o la contraseña. Por ello podría enviarse la contraseña mediante un Hash con Salt como:
21208C690B7ECCF92518D8055E9B361D.0A1B2C3D4E5F
Es decir, se adjunta la Salt.
Actualmente no obstante las tablas rainbow continuan siendo bastante útiles. Por ejemplo, pensar en los nombres de usuarios y contraseñas de Windows, los cuales son almacenados con un hash conocido como Hash NT. Use o no use Salt dicho hash, ya existen tablas precomputadas increiblemente eficaces capaces de revertir casi cualquier contraseña menor a 13 caracteres, use los caracteres que use.
Para acabar, vamos a ver como es posible revertir un Hash gracias a estas tablas. Vamos a ver lo “simple” que puede ser revertir un Hash MD5 que se ha enviado desde un PC cliente a un servidor para la autentificación en un foro o a un correo electrónico. Dado el tiempo necesario para precalcular una tabla hash “completa”, vamos a crear una tabla rainbow muy pequeña. En este caso he usado el software del proyecto RainbowCrack:
Caracteres: Letras minúsculas, es decir, de ‘a’ a la ‘z’
Longitud Mínima: 1
Longitud Máxima: 7
Indice de éxito: 98% de acierto
Cantidad de Cadenas por tabla: 4.000.000
Longitud de cada Cadena: 2.400
Tablas necesarias: 6
Tiempo de cómputo de las tablas: 6 Tablas *5 minutos por tabla = 25 min
Tamaño Total de las tablas: 366 MB, 61 MB por tabla
Línea de Comando usada:
C:\Users\Theliel\Desktop\rtgen md5 loweralpha 1 7 0 2400 4000000 0
C:\Users\Theliel\Desktop\rtgen md5 loweralpha 1 7 1 2400 4000000 0
C:\Users\Theliel\Desktop\rtgen md5 loweralpha 1 7 2 2400 4000000 0
C:\Users\Theliel\Desktop\rtgen md5 loweralpha 1 7 3 2400 4000000 0
C:\Users\Theliel\Desktop\rtgen md5 loweralpha 1 7 4 2400 4000000 0
C:\Users\Theliel\Desktop\rtgen md5 loweralpha 1 7 5 2400 4000000 0
Una vez las tablas han sido creadas y preparadas, tan solo es necesario introducir el hash que se desea invertir. La utilidad de dividir una tabla rainbow en trozos no es otro que evitar generar un solo archivo monstruoso, de esta forma es facil crear tablas rainbow con la ayuda de muchos voluntarios, cada uno por ejemplo podría generar una sola tabla. Con las tablas generadas, deberíamos de ser capaces de invertir con un 98% de acierto cualquier hash que venga de un nombre de usuario, contrasaeña… que contenga menos de 8 caracteres y esté en minúsculas sin números ni signos. Veamos ejemplos:
Usuario: 664DA32C1BA6F93F2899FE82C73DBFAF
Contraseña: B67885AB956F9D8F8946768F2E362E92
C:\Users\Theliel\rcrack *.rt -h 664DA32C1BA6F93F2899FE82C73DBFAF
traversing rt group #0 for 1 hash (remain = 0, traversed = 0, skipped = 0)
traversing rt group #1 for 1 hash (remain = 0, traversed = 0, skipped = 0)
disk: md5_loweralpha#1-7_0_2400x4000000_0.rt: 64000000 bytes read
searching for 1 hash…
disk: md5_loweralpha#1-7_1_2400x4000000_0.rt: 64000000 bytes read
searching for 1 hash…
plaintext of 664da32c1ba6f93f2899fe82c73dbfaf is theliel
disk: thread aborted
statistics
——————————————————-
plaintext found: 1 of 1
total time: 1.78 s
time of chain traverse: 0.41 s
time of alarm check: 0.11 s
time of wait: 1.15 s
time of other operation: 0.11 s
time of disk read: 1.67 s
hash & reduce calculation of chain traverse: 5752802
hash & reduce calculation of alarm check: 1171435
number of alarm: 1662
speed of chain traverse: 14.17 million/s
speed of alarm check: 10.65 million/s
result
——————————————————-
664da32c1ba6f93f2899fe82c73dbfaf theliel hex:7468656c69656c
C:\Users\Theliel\Desktop\rcrack *.rt -h B67885AB956F9D8F8946768F2E362E92
traversing rt group #0 for 1 hash (remain = 0, traversed = 0, skipped = 0)
disk: md5_loweralpha#1-7_0_2400x4000000_0.rt: 64000000 bytes read
disk: md5_loweralpha#1-7_1_2400x4000000_0.rt: 64000000 bytes read
searching for 1 hash…
traversing rt group #1 for 1 hash (remain = 0, traversed = 0, skipped = 0)
searching for 1 hash…
plaintext of b67885ab956f9d8f8946768f2e362e92 is talento
disk: md5_loweralpha#1-7_2_2400x4000000_0.rt: 64000000 bytes read
disk: thread aborted
statistics
——————————————————-
plaintext found: 1 of 1
total time: 0.76 s
time of chain traverse: 0.45 s
time of alarm check: 0.08 s
time of wait: 0.22 s
time of other operation: 0.02 s
time of disk read: 0.75 s
hash & reduce calculation of chain traverse: 5752802
hash & reduce calculation of alarm check: 1124940
number of alarm: 1624
speed of chain traverse: 12.73 million/s
speed of alarm check: 14.42 million/s
result
——————————————————-
b67885ab956f9d8f8946768f2e362e92 talento hex:74616c656e746f
Increíble, ¿cierto? En un par de segundos el hash ha sido invertido. Estas tablas podrían ser reutilizadas cada vez que se necesitase, aunque es evidente que las tablas creadas son limitadas. Imaginar el proceso con tablas mucho más completas. A día de hoy es posible invertir cualquier hash cuyo mensaje original sea menor a a unos 13 caracteres simples. Queda una incógnita por cubrir… en realidad infinitos mensajes de entrada pueden producir el mismo hash en la salida. Esto implica que en una misma tabla hash podrían ocurrir colisiones, en las que dos mensajes tienen el mismo hash. Lo normal en estos casos sería listar todas las posibilidades encontradas, el sentido común haría el resto.
¿Conclusión? Usar siempre contraseñas seguras, contraseñas de longitud nunca menor a 8 caracteres y usando combinaciones de letras mayusculas y minusculas, números y símbolos. De cara a un programador, jamás usar Hash sin salt. Las tablas Rainbow son un recurso poderosísimo como hemos podido ver, capaz de romper casi al instante un hash. La siguiente pregunta podría ser como puede un atacante obtener un hash, pero esto está indicado en el tema sobre Sniffing.
Brute Force y Diccionarios
Hasta ahora todo lo que hemos visto es como atacar a un Hash. Ahora veremos un par de sistemas que podrían ser usados prácticamente para atacar cualquier sistema criptográfico, ya sea un cifrado simétrico, asimétrico o un hash.
Brute Force es un término coloquial para designar un tipo de ataques que se versa simplemente en el poder computacional de los sistemas modernos. Brute Force (Fuerza bruta) básicamente lo que realiza es probar una a una todas las combinaciones posibles de una posible key (en caso de un cifrado) o posibles hash en caso de un hash. De echo, las tablas Rainbow serían algo así como unas tablas precomputadas brute force para los hash, ya que lo que contienen no es más que todas las posibles de la entrada. Las técnicas de fuerza bruta no obstante suelen quedarse como última solución, ya que su éxito o fracaso tan solo está directamente relacionado con la complejidad de la contraseña, y como hemos dicho ya por complejidad nos referimos al set de caracteres usado, así como a la longitud de esta.
La fuerza bruta clásica es simple de comprender. Imaginar que se tiene un maletín con apertura con combinación con 3 ruletas de números, que van entre 0-9 y cuya key hemos olvidado. Podríamos probar todas las opciones posible para tratar de adivinar cual es: “000, 001, 002, 003, 004… 997, 998, 999″. Serían unas 1000 combinaciones. Esto hacerlo a mano podría ser incluso factible, pero tan solo estamos hablando de 3 cifras (caracteres). Si transladamos esto a un algoritmo como AES cucya Key se desconoce, es exactamente lo mismo, serían necesarias unas 1000 combinaciones (Siempre hablando en el peor de los casos) para lograr la key. Pero que sucede si aumentamos ese “Set de caracteres”?
Actualmente la capacidad de cálculo de un procesador es impresionante, y si incluimos la posibilidad de poder usar nuestra tarjeta de vídeo para dicho propósito, podemos multiplicar incluso por x100 o x1000 el rendimiento!! Pero aun así, ¿hasta que punto es posible atacar con fuerza bruta un sistema? Primero tendríamos que presuponer una capacidad de cálculo estimada de nuestros sistemas, y a partir de ahí hacer suposiciones y aproximaciones de hasta que complejidad es viable atacar una key por fuerza bruta. El problema es que el tiempo para poder verificar una key u otra varía del algoritmo usado. Veamos algunos ejemplos sobre la capacidad de cómputo de un PC, las mostradas corresponden aproximadamente al PC usado en la redacción de este artículo:
Algoritmo CryptoZip: 50 Millones de contraseñas por segundo -> Clásico cifrado usado en archivos ZIP
Algoritmo AES-256: 1000 contraseñas por segundo -> Cifrado simétrico actual usado en archivos ZIP
Como podemos ver, hay más que ligeras diferencias. Con esos datos, podríamos por tanto esclarecer aproximadamente la viabilidad de poder romper una key en un tiempo razonable. Según esos datos, vamos a ver el tiempo estimado (máximo) necesario para romper diferentes ejemplos:
Key numérica CryptoZip de 13 caracteres de longitud: 67 horas -> viable
Key numérica CryptoZip de 17 caracteres de longitud: 257 días -> “viable”
Key minúscula CryptoZip de 11 caracteres de longitud: 884 días -> no viable
Key minúscula CryptoZip de 8 caracteres de longitud: 1.2 horas -> viable
Key minúscula+numérica CryptoZip de 11 caracteres de longitud: 86 años ->no viable
Key minúscula+numérica CryptoZip de 8 caracteres de longitud: 16 horas ->viable
Key minúscula+numérica+mayúscula CryptoZip de 9 caracteres de longitud: 9 años -> no viable
Key minúscula+numérica+mayúscula CryptoZip de 8 caracteres de longitud: 51 días -> “viable”
Key minúscula+numérica+mayúscula+símbolos CryptoZip de 8 caracteres de longitud: 3 años -> no viable
Key minúscula+numérica+mayúscula+símbolos CryptoZip de 6 caracteres de longitud: 3.2 horas -> viable
Key numérica AES-256 de 9 caracteres de longitud: 9 días -> “viable”
Key minúscula AES-256 de 7 caracteres de longitud: 97 días -> “no viable”
Key minúscula+numérica AES-256 de 6 caracteres de longitud: 26 días -> “viable”
Key minúscula+numérica+mayúscula AES-256 de 5 caracteres de longitud: 10.7 días -> viable
Key minúscula+numérica+mayúscula+símbolos AES-256 de 4 caracteres de longitud: 19.2 horas -> viable
De todos estos datos podemos sacar ciertas conclusiones. Cuando se está usando un algoritmo antiguo o relativamente rápido de verificar, sería posible recuperar keys de hasta 15 caracteres aproximadamente si es solo numérica, de unos 8-9 si contiene tan solo letras minúsculas y números, pero no más de 6-7 caracteres para keys que son complejas.
En caso de AES-256 es aun peor. En el mejor de los casos, tan solo podríamos intentar romper keys de hasta 9 caracteres de longitud si fuesen tan solo numéricas. Para el resto de los casos, contraseñas mayores de 4-6 caracteres que fuesen complejas serían imposible de romper por fuerza bruta al estilo más clásico.
No obstante existen multitud de técnicas basadas en fuerza bruta para mejorar en mucho estas cifras. Por supuesto, en el momento que sales del método tradicional, abandonas la posibilidad de lograr la recuperación al 100%. La idea es intentar mantener el mayor índice de porcentaje posible reduciendo al máximo el número de combinaciones posibles. El problema de este método es que suelen estar basados en la estadística y otras técnicas, en la suposición, en lo que podemos llamar “común”:
- Diccionarios: Se presupone que la key/contraseña escogida pertenece a una palabra que existe en un diccionario previamente creado o calculado. La idea nace de que lo normal es que las personas usen nombres comunes para sus claves y contraseñas. No obstante los diccionarios más sofisticados no solo incluyen aquellas palabras que existen en un lenguaje u otro, sino posibles alternativas a ellas. El diccionario contendrá aun así cientos o miles de millones de posibles opciones, pero siempre serán exponencialmente menos que combinaciones posibles por fuerza bruta.
Dado los múltiples problemas de esta técnica, suele usarse conjuntamente con métodos híbridos. Por ejemplo a la lista de entrada se le realizan modificaciones a todas sus letras de modo que se verifiquen todas las combinaciones posibles de cada entrada con letras mayúsculas o minúsculas. Así por ejemplo si tenemos la entrada “casa”, se probarán diferentes versiones de esta: “casa, Casa, cAsa, caSa, casA, CAsa, CaSa… CASA”. Esto hace aumentar enormemente el espacio de claves a probar, pero continuaría siendo exponencialmente menor a un ataque de fuerza bruta clásico.
Otra posible “optimización” a un ataque de diccionario es la combinación. Es una cuestión de conocer como piensan los usuarios. Si bien es cierto que existe un porcentaje alto de usuarios que usan palabras “naturales” para sus contraseñas/keys, también existe un porcentaje alto que cree que una combinación de estas dos palabras resulta en una contraseña más segura. Por ello, otra mejora habitual en los ataques por contraseña es permitir la combinación de dos, o incluso tres, palabras que se encuentran en el mismo diccionario. De este modo si en el diccionario tenemos las palabras: “casa” y “antonio”, nuestro ataque comprobaría: “casa, antonio, casaantonio, antoniocasa”.
Los ataques de diccionario son increíblemente rápidos, pero en contrapartida son completamente ineficaces cuando la contraseña/key usada no se encuentra en ellos, lo cual es facil si se crea esta sin ser una “palabra” con “sentido”.
- Fuerza bruta “inteligente”: La idea ha sido siempre reducir al máximo las combinaciones posibles. El diccionario es una técnica realmente eficaz, pero depende enormemente del diccionario, del lenguaje… y por supuesto del usuario y la contraseña que haya podido establecer. La fuerza bruta establece que cualquier combinación es posible (y realmente es así), en cambio esto no es cierto si se atienden a las estadísticas de los usuarios, contraseñas comunes, palabras empleadas, frases empleadas… lo cual lleva a replantearse la fuerza bruta. ¿Es posible eliminar combinaciones (estadísticamente hablando) por ejemplo si tenemos una key de hasta 8 caracteres en minúsculas? La estadística dice que existen combinaciones de letras que jamás se darán. Por ejemplo, no existen palabras en español que estén constituida por dos letras seguidas, excluyendo la “erre” y la “ele” (quizás exista alguna, pero el ejemplo es claro). Esto hace eliminar de un plumazo una cantidad considerable de combinaciones. Esto crea una serie de normas que van eliminando combinaciones y más combinaciones al ataque de fuerza bruta clásico, por ejemplo interpretando las letras que pueden ser usadas al inicio o al final, letras que suelen ir juntas o letras que no…
Este tipo de fuerza bruta decrementa enormemente las posibles combinaciones, lo que hace que el ataque pueda ser llevado a cabo mucho más rapido. En contra partida de nuevo tenemos que un usuario podría siempre crear una key/contraseña que se saltase estas medidas. Por ejemplo la contraseña: “tYb,3hI?” sería imposible de detectar por ningún sistema casi con toda seguridad, tan solo por fuerza bruta clásica.
- Plantillas: Con plantillas nos referimos a la posibilidad de poder acotar la búsqueda de una key por fuerza bruta basándonos en ciertas reglas que nosotros mismos especificamos. Por ejemplo una plantilla podría ser simplemente especificar los primeros 4 caracteres de la contraseña, dejando para la fuerza bruta tan solo otros 4. O por ejemplo una plantilla podría ser igualmente especificar una palabra que estamos seguro que la clave contiene, dejando a la fuerza bruta que compruebe todas las posibilidades teniendo en cuenta que existen por ejemplo 4 caracteres que siempre estarán juntos, estén al inicio, en medio, al final…
El problema con las plantillas es que dependen casi en su totalidad en lo que se pueda conocer a la víctima y que tipo de palabras ha podido usar. Pensar por ejemplo en fechas de cumpleaños, aniversarios… podríamos especificar por ejemplo que se verificasen todas las combinaciones posibles de hasta 12 caracteres que contengan la fecha “22051950″. Dado que son 8 caracteres, tan solo serían 5 caracteres por combinar, es decir, los 4 caracteres restantes que completarían los 12 caracteres más la fecha en sí, que sería tratado como un carácter más.
De nuevo la eficacia dependerá de factores externos, como lo bien o mal que se conozca a quien puso la contraseña, a la suerte, a la perseverancia…
Posiblemente, uno de los “crackers” más famosos fue siempre John The Ripper, que fue creado originalmente para lograr obtener las contraseñas de Unix, almacenadas todas ellas tradicionalmente en un hash basado en DES (cifrado simétrico). Con el tiempo, el soporte para este “crackeador” de contraseñas fue ampliándose, soportando otros hash como los que usa Windows para almacenar sus claves de sesión. Esto puede hacernos pensar que el uso de la fuerza bruta ha ido cada vez más relegándose a un segundo plano, dada la complejidad del calculo necesario para poder computar contraseñas/key actuales. En cambio, la fuerza bruta posee dos cualidades únicas que hacen que posiblemente siempre sea una opción viable a considerar. Esto es así por dos motivos:
El primero, la fuerza bruta tiene un índice de probabilidad del 100% y teóricamente “siempre” podrán realizarse (en realidad existen métodos criptográficos en los que la fuerza bruta no es posible realizarse), solo es cuestión de tiempo, ya sean 1000 años o dos segundos.
La segunda característica, es que aunque sea necesario un mayor tiempo de cómputo o se usen cada vez keys más largas y complejas, la capacidad de cálculo actual se va incrementando de igual modo. Lo que actualmente un PC puede llevar a cabo en un año, simplemente por tener una tarjeta de video por ejemplo con soporte para CUDA, puede ser suficiente para reducir ese año a simplemente algunos segundos. Esto es posible a que la capacidad de cálculo en paralelo de una tarjeta de vídeo es muy superior a un procesador tradicional. Por ejemplo, es posible que la nueva generación de tarjetas de nVidia, la esperada familia basada en Fermi, pueda incrementar en un x10000 la velocidad de cómputo de contraseñas AES-256 especificadas anteriormente, eso hace que de 1000 contraseñas por segundo se pase a lo mejor a 10.000.000 de contraseñas por segundo. Es decir, no hay que perder de vista jamás que las capacidades de cálculo son mejoradas cada día, tanto tarjetas de vídeo como procesadores. Lo que hoy no es viable, mañana puede ser completamente viable.
El mejor ejemplo de esto es RSA. Es imposible factorizar en tiempo factible una key RSA-1024… pero esto tan solo es cierto a medias. Quizás fuese imposible hace unos años, quizás es imposible actualmente… pero cada día que pasa es más posible. Eso hace que actualmente RSA-1024 esté siendo sustituido casi en su totalidad a RSA-2048, es casi seguro que que vivamos para ver que RSA-4096 es lo mínimo para mantener el sistema seguro. Es decir… Brute Force será posiblemente siempre una técnica usada y que tendrá siempre una efectividad decente.
Para acabar, vamos a ver lo simple que es usar John The Ripper para extraer las contraseñas de usuario de un iPod/iPhone. Todos sabemos que cuando se le realiza JB es posible acceder a él por medio de SSH. También sabemos que posee dos usuarios: “root” y “mobile”, y que en ambos la contraseña es “alpine”. ¿Pero como se ha llegado a esta disertación? ¿A caso Apple ha filtrado estas contraseñas? Vamos a extraerlas.
Lo primero que necesitamos es conocer en un sistema Unix en que archivos se almacenan las contraseñas. Esto se hace normalmente en uno o en dos, dependiendo si se está usando un ocultador o no. Si no se está usando, lo normal es que estas contraseñas y usuarios se encuentren en un archivo llamado passwd, que contiene los nombres de usuarios y las contraseñas en un hash-cifrado basado en DES llamado shadow. Dichos archivos en el iPod/iPhone se llaman “passwd” y “master.passwd”.
Una vez se obtienen ambos archivos, se debe de generar un archivo único que integra ambos archivos (esto es así por el propio sistema que usa UNIX para ello). Una vez obtenido este archivo único se realizaría un ataque de fuerza bruta. Dado que UNIX usa un hash muy débil (basado en DES), es fácil romperlo:
C:\Users\Theliel\Desktop\>unshadow passwd master.passwd > contra
“contra” es el archivo “unificado”
C:\Users\Theliel\Desktop\>john contra
Loaded 2 password hashes with 2 different salts (Traditional DES [64/64 BS MMX])
alpine (mobile)
testtest (root)
guesses: 2 time: 0:00:10:47 (3) c/s: 2134K trying: testtart – testzirz
Para esta prueba, la contraseña de la cuenta mobile fue establecida de nuevo a su contraseña origen, y la contraseña root fue establecida a “testtest” para tener una contraseña con longitud de 8 caracteres. Hay que tener en cuenta que iPod/iPhone no soporta contraseñas mayores de 8 caracteres. Se puede observar como el ataque tubo éxito, siendo necesario tan solo unos 11 minutos en llevarse acabo. Este ataque de fuerza bruta difiere quizás un tanto del clásico ataque de fuerza bruta, dado que va dirigido a un Hash y no a un cifrado, pero básicamente es exactamente igual.
Si las tablas rainbow nos enseñaron a la necesidad de crear siempre los hash con salt, la fuerza bruta y todas sus variantes nos enseñan que la mejor protección ante este tipo de ataques no es solo un buen sistema de cifrado, sino una key, contraseña, clave de paso… que sea segura, con una longitud decente, que no sea personal, que… cuando se toman las medidas oportunas, este tipo de ataques está evocado al fracaso.
Criptoanálisis
El término Criptoanálisis es un poco ambiguo en la medida que podríamos considerar como “criptoanálisis” prácticamente cualquier ataque que queramos realizar contra la criptografía. En cambio podríamos, como ya dije en su momento tomar por criptoanálisis tan solo aquellas técnicas, generalmente estadísticas en combinación (o no) con otras, para lograr el resultado deseado, que puede ser desde la roptura completa de un sistema obteniendo una key, accediendo simplemente a la información cifrada o… así por ejemplo, la paradoja del cumpleaños aunque es usada para crear colisiones en los hash, podría interpretarse como tal como un sistema de criptoanálisis.
Esto no es un método nuevo creado en el siglo XXI, sino bastante antiguo. La idea de estudiar un manuscrito e intentar descifrarlo la conocemos desde los mismos jeroglíficos a notaciones musicales o muchos lenguajes ya desaparecidos. ¿Por qué? Es fácil, la mejor forma de “traducir” (aquí usamos el término descifrar) algo que se desconoce es buscar patrones en común, palabras que se repitan constantemente, distribución de los caracteres a lo largo del escrito… todo ello ayuda sobremaneramente para lograr una “traducción” de algo desconocido. En el caso de la criptografía en realidad es muy similar. Un ejemplo claro de criptografía lo encontramos cuando se habló de los diferentes modos de cifrado de los bloques de criptografía simétrica, en el que se sometió el cifrado CBC a un test sobre una imagen para verificar su fortaleza. En realidad, ese test lo que hace es mostrar gráficamente una serie de patrones repetidos por toda la imagen.
Entre los ataques de criptoanálisis más comunes podemos encontrar:
- Análisis de Frecuencias
- “Texto codificado” conocido
- “Texto plano” conocido
- Texto plano/codificado escogido
El análisis de frecuencias pudimos ya comprobarlo cuando vimos el método de codificación por bloques CBC. Pero puede ilustrarse de un modo aun más simple. Imaginar por ejemplo el cifrado de sustitución más simple, en el que cada letra del abecedario se mapea a otra letra de este. La key por tanto sería tan solo este mapeo. Es decir, si la Key fuese:
ZYXW….
Significaría que la A sería sustituída por la Z, la B pro la Y, la C por la X… para descifrar un texto de esta forma, tan solo tendría que tener la otra parte la mismaplantilla. Al leer Z la sustituiría por una A, las Y por B… este tipo de cifrado aunque pueda parecer trivial ha sido muy usado en la antigüedad. Hay que tener en cuenta que las matemáticas modernas, así como los dispositivos de computación que tenemos a día de hoy no se encontraban disponibles muchos años atrás, y que un cifrado tan aparentemente simple como el explicado podía ser suficiente para que, por ejemplo, dos amantes compartiesen cartas comprometidas, sin que ninguna tercera persona lograse descifrarlas.
Es cierto que con los sistemas modernos de codificaciones por bloque, los análisis de frecuencias van teniendo cada vez menos interés como método directo para estudiar un cifrado, no obstante continúa siendo usado tanto para verificar la resistencia de un buen cifrado como en la búsqueda de otros sistemas mucho más sofisticas en combinación con estos.
Estos análisis de frecuencias han sido muy usados durante muchos años, y a día de hoy constituyen siempre un comienzo a la hora de estudiar un cifrado concreto. Podríamos destacar igualmente el método de Kasiski, similar al que vamos a ver a continuación, pero orientado a conocer la longitud de las palabras, o extender el análisis de frecuencia al índice de coincidencia. Dependiendo de que tipo de cifrado sea, quizás sea mejor usar un método u otro. Para quien quiera jugar con todo esto, les recomiendo una vez más Cryptool.
Vamos a crea un ejemplo con el cifrado más básico de sustitución y verificar que con un ataque de análisis de frecuencia es posible recuperar el texto original. Gracias a ello, se podrá ir recuperando al mismo tiempo la “key” usada en el cifrado de dicho mensaje. Para llevar esta labor a cabo, tendremos que partir de un texto cifrado por sustitución, e intentar obtener el mensaje original a partir de este. Para este ejemplo he partido de un pequeño fragmento de “El Zahir”, un libro de Paulo Coelho (gran escritor, el libro es mu interesante igualmente). Dicho fragmento ha sido procesado con CryptoTool para generar un texto cifrado por sustitución usando una key aleatoría. Recordar que la key no es más que un mapeo de un carácter a otro, en el que ningun caractar en este caso está repetido, es decir, la asociación es 1 <– >1:
piczyiugwtxhzrxibkziqejiywxbikkziynwiqngsijmnifgypzjwzeirwjpigbaztxjugin
ikkitiyczypzikkzugiikkznirwfznwjzbrxnizkxyxsxykzjzvxbexjkzugiyiagiyxkxibp
xbhiynikwljzjirinwvzcwjibhzyxhxbpjzjwxeibyzjirwzmbxhcibxhcimrwzjihxjrzb
rxbgiypjzcwypxjwzhwibpxynwkiyritihiywbpibpzbrxriyhgljwjiknxnibpxibikugi
niiugwtxugimbgiypjxyhznwbxyineivzjxbzrwypzbhwzjyi
Al texto superior se le han eliminado tanto signos de puntuación como espacios, para que no sea posible percibir inicios o fin de palabras. Podemos ver el esquema que se ha usado para realizar esto:
Un texto original se cifra por medio de sustitución con una “key” que descnonocemos. Después de realizar la operación de cifrado, enviamos como texto plano el resultado para poder visualizarlo: “Texto cifrado”. Al mismo tiempo, la salida cifrada se pasa de nuevo por el descifrador que debería de devolvernos el texto original reconstruido: “Texto Reconstruido”. Dado que no hemos comenzado a aplicar el análisis de frecuencia, actualmente el texto Reconstruido es exactamente igual al texto cifrado. Por último se puede observar como a la salica cifrada se le ha aplicado un pequeño analizador de frecuencia, el cual nos devielve el porcentaje de aparición de cada letra. Visto de una manera más gráfica tenemos:
Frecuencia de caracteres del Texto Cifrado
Con estos datos, podemos comenzar por tanto un sistema de deducción basado en la estadística. Según la gráfica superior, el 16,37% de todos los caracteres son “I”, el 9.82% “Z”… ¿Como nos vale esto? Recurriendo ni más ni menos que a la estadística. Estos son los datos obtenidos de nuestro texto cifrado. ¿Pero que dicen las estadísticas del lenguaje castellano de forma general? Es decir, si conociésemos la frecuencia “global” media de las letras escritas de nuestro lenguaje, podríamos comenzar a deducir y reemplazar. En mi caso he usado como referencia la frecuencia de caracteres de “El Quijote”. Con cerca de medio millón de palabras, puede servir a groso modo como dato “fiable”. Lo ideal sería establecer una frecuencia basada en diferentes tipos de textos, a poder ser mucho más largos. Pero a modo de ejemplo es suficiente:
Frecuencia de Caracteres de "El Quijote"
Con este patrón que creemos “fiable” podemos por tanto comenzar a conjeturar. Según la frecuencia basada en “El Quijote”, las vocales ‘E’ ‘A’ y ‘O’ serían las letras con mayor frecuencia y en dicho orden. Si estableciésemos una correspondencia directa entre ambos análisis, tan solo tendríamos que sustituir las vocales citadas por aquellos caracteres con mayor frecuencia en el texto cifrado, que serían en el mismo orden: ‘I’ ‘Z’ y ‘X’. Si volvemos a CryptoTool y añadimos dichas letras en las posiciones adecuadas, comenzaremos a tener una primera versión de texto reconstruido, siempre y cuando la hipótesis aplicada de frecuencias sea correcta: ‘I = ‘E’, ‘Z’ = ‘A’, ‘X’ = ‘O’
pecayeugwtoharoebkaeqejeywobekkaeynweqngsejmnefgypajwaeerwjpegbaatojugen
ekketeycaypaekkaugeekkanerwfanwjabroneakoyosoykajavobeojkaugeyeageyokoebp
obheynekwljajerenwvacwjebhayohobpjajwoeebyajerwambohcebohcemrwajehojrab
robgeypjacwypojwahwebpoynwkeyreteheywbpebpabroreyhgljwjeknonebpoebekuge
neeugwtougembgeypjoyhanwboyeneevajobarwypabhwajye
Aun con 3 posible letras descodificadas, es imposible tener algo legible. Eso sí, hay que tener en cuenta que cada letra que es sustituídas y dado que es una sustitución 1 <–> 1, implica que para el resto de los caracteres las posibilidades van decreciendo igualmente. Podríamos continuar con las dos siguientes, pero si contemplamos las estadísticas de nuestro texto cifrado, tanto la ‘B’ como la ‘Y’ poseerían un porcentaje igual. En cambio si acudimos a las frecuencias de nuestros datos muestra, tenemos que las dos siguientes letras corresponderían a la ‘S’ y la ‘N’ en dicho orden. No obstante, podemos acudir a la frecuencia de repetición de dos caracteres juntos iguales. Si lo hacemos, obtenemos que los caracteres más repetidos (en parejas) correspondiente a nuestro texto cifrado son:
II: -> 2 apariciones, 0,59% del total
KK -> 4 apariciones, 1,18% del total
Y del mismo modo para nuestro texto de muestra:
LL:9258:0,00467523338292373
RR:2378:0,00120087545739821
De forma aplastante, LL es el carácter más repetido estadísticamente en nuestros datos de muestra. Si observamos los caracteres repetidos en nuestro texto cifrado tan solo tenemos dos, II y KK. No obstante, ‘I’ =’E', luego podríamos asumir sin duda alguna que ‘K’ = ‘L’. Al ser un texto pequeño, no disponemos de otros caracteres dobles que podamos sustituir por ‘R’. Pero al igual que tenemos carácteres dobles ampliamente usados en nuestro lenguaje, también tenemos combinaciones de 3 caracteres que prevalecen sobre las demas, como es el caso de ‘QUE’. Estadísticamente es la asociación de tres letras más repetida con muchísima diferencia. Si examinamos las agrupaciones de 3 caracteres en nuestro texto cifrado, existe curiosamente una asociación de 3 caracteres con un 1.46% de aparición, que corresponde a las letras ‘UGI’, si tenemos en cuenta además que la ‘I’ es una ‘E’, es evidente que U = Q y G = U
pecayequwtoharoeblaeqejeywobellaeynweqnusejmnefuypajwaeerwjpeubaatojquen
elleteycaypaellaqueellanerwfanwjabronealoyosoylajavobeojlaqueyeaueyoloebp
obheynelwljajerenwvacwjebhayohobpjajwoeebyajerwambohcebohcemrwajehojrab
robueypjacwypojwahwebpoynwleyreteheywbpebpabroreyhuljwjelnonebpoebelque
neequwtoquembueypjoyhanwboyeneevajobarwypabhwajye
Con el trabajo realizado por ahora, es posible ir dividiendo ya algunas de las palabras que van apareciendo, y sustituir también la ‘W’ = ‘I’, dado que es la vocal que nos resta, y después de QU -> es evidente que si no es una ‘E’, será una ‘I’. Con todas las vocales despejadas, y aun sin conocer cuales corresponderían estadísticamente a la ‘N’ y la ‘S’, si nos restaría con una probabilidad de 6.85% la ‘J’ de nuestro texto cifrado, que equivaldría a ‘J’ = ‘R’ en nuestros datos de muestra. Podemos por tanto agregarlo todo:
pecay equitoharoeblaeqereyiobellaeynieqnusermnefuypariaeerirpeubaatorquen
elleteycaypaella que ella nerifanirabronealoyosoylaravobeorlaqueyeaueyoloebp
obheynelilrarerenivacirebhayohobprarioeebyareriambohcebohcemriarehorrab
robueypraciyporiahiebpoynileyreteheyibpebpabroreyhulrirelnonebpoebelque
ne equitoquembueyproyhaniboyeneevarobariypabhiarye
Con ello podemos deducir sin mucho trabajo, ahora sí: ‘bueyproy’ que ‘B’ = ‘N’ e ‘Y’ = ‘S’, no hay más remedio, y poder formar así ‘NUESXRO/S’, con lo que además obtenemos también ‘P’ = ‘T’:
te cas equitoharo en la eqeresion ella esnieqnuserm ne fustaria eerirte unaatorquen
elletescastaella que ella nerifaniranronealosososlaravoneorla que se auesoloent
onhesnelilrarerenivacirenhaso hontrario eensare riamnohcenohcemriarehorranro
nuestra cistoria hientosnilesretehes intentanroreshulrirel nonento en el que
ne equitoque m nuestros haninos eneevaronaristanhiarse
Lo cual nos hace resolver del todo el texto cifrado. Si sustituimos la ‘H’ = ‘C’, ‘N’ = ‘M’, ‘M’ = ‘Y’, ‘F’ = ‘G’, ‘E’ = ‘P’, ‘R’ = ‘D’
te has equitohado en la eqpresion. ella es mi eqmuser y me gustaria pedirte un aatorque
me lletes hasta ella, que ella me diga mirandome a los osos la ravon por la que se aue solo entonhes
melilrare de mi vacir en caso contrario pensare ria y noche noche y ria recordando
nuestra historia cientos miles de teces intentando desculrir el momento en el que
me equitoque y nuestros caminos empevaron a distanciarse
Por último, solo nos queda terminar de colocar las pocas letras que nos quedan, añadir los espacios que nos restan y en todo casi si queremos añadir acentos, comas y otros para que el texto tenga mayor sentido. El texto descifrado correspondería a:
“Te has equivocado en la expresión. Ella es mi ex-mujer y me gustaría pedirte un favor: Que me lleves hasta ella, que ella me diga mirándome a los ojos la razón por la que se fue. Solo entonces me libraré de mi Zahir. En caso contrario pensaré día y noche, noche y día… recordando nuestra historia, cientos, miles de veces, intentando descubrir el momento en el que me equivoqué y nuestros caminos empezaron a distanciarse”
Texto codificado conocido puede parecer una perogrullada, parece evidente que siempre tendremos acceso al texto codificado, máxime cuando precisamente lo que se quiere realizar es desencriptarlo. Pero se especifica para indicar que tan solo tenemos acceso a dichos mensajes codificados. Un ataque de estas características implicaría estudiar tan solo los mensajes cifrados, y a partir de ellos lograr de alguna forma invertir el cifrado de estos, recuperar la key o lo que sea posible. Parece imposible a simple vista que simplemente por el estudio de estos mensajes cifrados se pueda llevar a alguna conclusión, en cambio ya vimos por ejemplo con el análisis de frecuencia (que realmente se aplica a un mensaje ya cifrado) que esto es posible.
Un ejemplo muy interesante sobre esto es una de las muchas vulnerabilidades de WEP, ese “sistema de seguridad” WIFI que aun está implantado en más de un 50% de los hogares, me atrevo a decir. WEP usa como vimos en su momento un sistema de cifrado simétrico basado en flujo, en concreto el algoritmo se conoce como RC4, y básicamente lo que hace es generar un flujo constante de bits que hacen de key para los datos que se van enviando/recibiendo, y dicho flujo es al mismo tiempo generado en el otro punto de la comunicación. La forma en la que se cifran los datos en RC4 dijimos que era realizando una operación lógica XOR entre el mensaje original y la key del stream (del flujo). El problema aparece cuando dos mensajes diferentes son encriptados con la misma key-stream. ¿Como es esto posible? es simple, si la key maestra no se modifica, la key-stream generada no será modificada tampoco. Para evitar que la key-stream se pueda repetir, se usa un vector de inicialización que se concatena con la key maestra, y a partir de dicha asociación se genera el stream necesario. Cada paquete enviado incluirá un vector de inicialización diferente, generado aleatoriamente, y que será transmitido al medio sin cifrar conjuntamente con el paquete cifrado, para que de este modo, los destinos puedan conoce el IV usado, concatenar el IV (vector de inicialización) con la key maestra que tienen y con ello generar el key-stream del paquete para poder desencriptar el contenido.
En teoría podría parecer un sistema seguro, el key-stream es diferente en cada paquete, con lo que no hay duplicación de key-stream. El problema es que el vector de inicialización de WEP es de 24 bits, es decir… es muy pequeño. ¿Que probabilidad existe de que se produzca una colisión? Es decir… ¿que se generen dos IVs iguales? podríamos decir que 224 pero como quedó ya constante, por la paradoja del cumpleaños esto no es así:
X(P,Y)= Raiz (2Y Ln (1/1-P))
Para una probabilidad de 0.99 (99%) necesitaríamso en el peor de los casos 12.431 paquetes aproximadamente. Es decir, cada trece mil paquetes wep, al menos dos estarán usando la misma key.
Ahor abien… ¿como influye esto? Tan solo hay que saber que la operación lógica XOR posee la propiedad conmutativa (y por supuesto su tabla de verdad). Imaginar por tanto que tenemos en nuesras manos 2 mensajes diferentes cifrados con la misma key-stream:
A y B son los mensajes, Cifrado (A) y Cifrado (B) los mensajes que hemos capturado, los cuales comparten la misma key. K es la key del paquete, es decir, la concatenación de la Master Key y el IV. Sk (K) sería por tanto la key-stream
Cifrado (A) = A XOR Sk (K) -> El cifrado de A se forma mediante el mensaje original y XOR key-stream
Cifrado (B) = B XOR Sk (K) -> El cifrado de B se forma mediante el mensaje original y XOR key-stream
Cifrado (A) XOR Cifrado (B) -> Por la propiedad conmutativa y con las ecuaciones superiores tenemos que:
(A XOR Sk (K)) XOR ((B XOR Sk (K)) = A XOR B XOR Sk (K) XOR Sk (K) -> Sk (K) XOR Sk (K) = 0 por definición
Cifrado (A) XOR Cifrado (B) = A XOR B
Es decir, si se realiza la operación XOR entre ambos mensajes encriptados, el resultado es el mismo que si se realiza la operación XOR a los mensajes no cifrados. La utilidad es inmediata, dado que sería posible descifrar el contenido de los mensajes originales, en el peor de los casos haciando un poco de fuerza bruta. Un ejemplo:
k 1= IV | MK
ks = RC4(k1)
A= 01011
B= 01101
ks= 11011
Cifrado (A) = 10000
Cifrado (B) = 10110
Cifrado (A) XOR Cifrado (B) = 00110 = A XOR B -> Se cumple!!
Se podría pasar a usar ahora por ejemplo fuerza bruta para intentar descubrir los posibles mensajes originales. Es cuestión de analizar las probabilidades que existen de encontrar el mensaje original, e ir probando. En el momento además que se obtenga uno de los mensajes, el otro es encontrado de forma automática también.
Acabamos de ver lo que entendíamos por la técnica de “texto cifrado conocido”, del mismo modo tenemos también la técnica conocida como “texto plano conocido“, en la que ahora no solo disponemos del texto cifrado, sino que también disponemos de todo o parte del contenido original. Es evidente que en este caso lo deseado no es obtener algo que ya tenemos. La idea es recuperar el resto del mensaje cifrado en caso de que tan solo tengamos el mensaje parcial o por el contrario ser capaces de recuperar la key original por medio de esta técnica.
Posiblemente el mejor ejemplo de “texto plano conocido” que podemos encontrar sea el sistema usado por el compresor ZIP. Esta técnica permitía extraer todos los archivos cifrados de un ZIP, sin necesidad de contraseña, simplemente poseyendo un archivo sin cifrar que estuviese ya dentro de dicho ZIP. Es decir, imaginar un archivo ZIP encriptado con una contraseña con las fotos más comprometidas de nuestros hermanos. Imaginar que tenemos alguna foto que el nos ha enseñado sin encriptar, fuera del ZIP. Podríamos recuperar todo el contenido.
Otro ejemplo podría ser también un cifrado como el que hemos hablado antes, de sustitución. Con saber una letra o un par de ellas del mensaje original, podría ser suficiente con suerte para llegar a deducir el resto. No hablo solo al cifrado de sustitución que ya mostré, sino alguno que pueda ser más complejo. De todos modos, es un sistema relativamente poco efectivo en los métodos de codificación modernos, siendo realmente vulnerabilidades de las propias implementaciones las que hacen posible este tipo de ataques y no el cifrado en sí.
Por último, podríamos disponer ya no solo material cifrado o sin cifrar como el que hemos visto, sino que material cifrado o sin cifrar que nosotros escogemos a conciencia para poder realizar nuestro criptoanálisis. Se conoce como “texto escogido”. Normalmente esta no es una opción viable, dado que es complicado poder disponer de un material cifrado o sin cifrar que hemos seleccionado previamente. No podemos decirle a una persona a la cual le interceptamos un mensaje que nos envíe otro mensaje tal y como nosotros lo queremos. Es decir, esta técnica queda reservada a un “pequeño” grupo, no de manera generalizada.
Por un lado tenemos los cifrados asimétricos, en los cuales en cualquier momento si que podemos disponer de cualquier material cifrado y sin cifrar que provenga de la clave pública del objetivo. Es cierto que no podremos disponer de texto escogido cifrado que provenga de su clave privada, pero al menos ya es algo. Es más, muchos de los ataques que se han realizado a sistemas RSA, han estado basados en textos escogidos para poder lograr (o no) la key privada. Aunque normalmente, estas vulnerabilidades suelen ser más propias de las implementaciones. Por ejemplo, sería muy interesante ver el comportamiento de una implementación SSL/TLS frente a lo mejor un mensaje creado a propósito que tan solo contiene una cadena inmensa de contenido vacío (0×00), o variar la longitud a voluntad para ver que tipo de Padding se está usando, o intentar… es decir que las opciones son múltiples. Es una herramienta muy poderosa, pero como hemos dicho reservada tan solo a escenarios bastante concretos.
Por otro lado podríamos tener aquellos sistemas en los que pudiésemos “obligar” a un cliente a enviarnos material específico. Esta por ejemplo es otra vulnerabilidad de nuestro ya más que hablado WEP, y es además como la mayoría de los atacantes logran recuperar las contraseñas WEP de los usuarios que aun las usan. Este ataque está basado por ejemplo en el reenvío masivo de paquetes ARP (ARP no será tratado en estas líneas). WEP no modifica en modo alguno la longitud de los paquetes, recordar que usa XOR para cifrarlos. ARP por otro lado son paquetes con una longitud determinada y que son fácilmente reconocidos por cualquiera, incluso estando cifrados. Estos paquetes ARP que son ampliamente conocidos, tienen una cabecera de 16 bytes que es común a todos ellos!. Es decir, los primeros 16 bytes de un paquete ARP son siempre los mismos, exactamente:
AA AA 03 00 00 00 08 06 -> Los primeros 8 Bytes de un paquete ARP
00 01 08 00 06 04 00 01 -> Los 8 Bytes siguientes de un paquete ARP
El último byte no obstante varía entre 01 y 02 si el paquete ARP es un “response” o un “request”. Por otro lado, dado que la MAC del frame no es cifrada por WEP, conocer si el paquete es un ARP response o un ARP request es sencillo (mirando el destino de la MAC o el origen de ella).
En ese momento ya conoceremos los primeros 16 bytes cifrados de u paquete ARP (enviados por el AP) y los 16 primeros bytes del paquete ARP sin cifrar (deducidos). Dado que los datos son cifrados por medio de XOR, si se realiza un XOR a los datos cifrados con los datos sin cifrar da exactamente la key usada para cifrarlos. Es decir, fácilmente podemos recuperar desde un paquete ARP 16 bytes de la key-stream, y dado que el IV se envía también sin encriptar, también se dispondrá del IV empleado para concatenar la master key que se usó para generar el key-stream
Para poder realizar un ataque completo a WEP es necesario la recolección de cierta cantidad de key-stream, cuando se obtiene dicha cantidad, por medios probabilísticos y un poco de fuerza bruta es posible la obtención de la key:
Side Channel
Por último, vamos a hablar del último grupo de posibles ataques a sistemas cifrados que podemos encontrar. Se llaman métodos Side Channel, es decir, métodos “paralelos”, realmente no buscan encontrar vulnerabilidades en el propio cifrado, sino que normalmente en el sistema en el que están implementados o en el medio por el que circulan dichos datos. Ojo!! no a la implementación de ellos!! sino en el sistema que son implementados. Para ello se estudia el comportamiento de dichos sistemas ante un cifrado o un descifrado.
Posiblemente a día de hoy sea el mayor riesgo para los cifrados. Dado que todos estos sistemas están siendo utilizados de un modo u otro en un hardware, este hardware se comportará siempre de manera diferente dependiendo de los datos que circulen por él. Por ejemplo, cuando se está descifrando un código en un PC, algún lugar de este se está procesando dicha Key. Por muy seguro que sea el cifrado si la key se encuentra en dicho momento en memoria, un atacante con acceso a dicho sistema podría intentar recuperar dicha key de la memoria del sistema. O quizás más famosos aun son los ataques de tiempos, que estudian el tiempo que requiere el procesador, la memoroa, la caché… en procesar el encriptado/desencriptado de los datos. En definitiva, la idea es estudiar el entorno y conocer como se comporta este ante diferentes tareas en el cifrado. Esto puede parecer ciencia ficción, pero realmente funciona, y supone u verdadero riesgo para los cifrados simétricos o asimétricos, así como a todas las comunicaciones a día de hoy.
Posiblemente los Side Channel más conocidos sean:
- Arranque en frío e inicio alternativo
- Monitorización del hardware
- Extracción directa
- Análisis Electromagnético
- Análisis de consumo y de estados
- Ataques de tiempo
Cold Boot o arranque en frío es una técnica destinada a la extracción de keys que son usadas por un sistema que aun estén residiendo en la memoria de este. Para que un sistema (ya sea un PC, un procesador criptográfico, un dispositivo portátil…) pueda utilizar una key, esta debe de pasar antes a su propia memoria RAM. La memoria RAM de estos dispositivos suele ser volátil, es decir, su información se pierde (se va degradando paulatinamente) inmediatamente después de que el suministro energético ha sido retirado. Es decir, mientras el sistma está arrancado, es normal que por ejemplo los módulos TPM de los que ya hemos hablado mantengan las Keys en la RAM de estos, que el PC arrancado en Windows tenga las Key de BitLocker o EFS en la memoria del sistema, que la key privada de nuestra smartcard esté en la RAM de este cuando se está usando… etc etc. Lo que sucede es que mientras el sistema está arrancado o en funcionamiento, estas keys pueden estar residiendo en la memoria si se están usando, pero tan solo mientras el sistema está conectado. Al cerrar el sistema y la alimentación se corta, la RAM deja de tener coherencia y los datos simplemente se desvanecen.Es por ello que la memoria necesita lo que se denominan ciclos de refresco, en los que la información de esta es reescrita de nuevo en ellos para que esta pueda mantener su información intacta. Al cortar la energía no se refrescará, con lo que la información se pierde. Esto lo observamos por ejemplo cuando un equipo está en suspensión. Un PC en suspensión en modo S3, deshabilita prácticamente todo el hardware del sistema… menos la RAM, la RAM continuará estando alimentada, refrescándose cuando sea necesario para poder mantener los datos.
Lo que sucede realmente es que esto no es algo inmediato. La información en la RAM no se desvanece de forma inmediata nada más apagar el sistema ni mucho menos, tiene un período de tiempo estimado, en el que a partir de dicho tiempo es una cuestión de probabilidad, hasta que hayan desaparecido del todo. ¿Cuanto es este tiempo? Depende de mil factores, lo que es seguro es que si la RAM se vuelve refrescar, los datos de esta se fijarán. Imaginemos ahora que tenemos ante nosotros un PC en suspensión S3, el cual sabemos que usa BitLocker o EFS para proteger su equipo. Nosotros sabemos que casi con toda seguridad en algún lugar de la memoria se encuentran las keys necesarias para poder acceder al sistema, dado que el propio sistema está arrancado y funcionando. Y aquí es donde aparece el Arranque en frío. Imaginar que durante unos instantes cortamos la energía al sistema, pero la volvemos a restablecer de forma que intentemos mantener intacta la mayor parte de la RAM posible. Al arrancarlo, dado que la RAM es posible que aun mantenga las keys en memoria, podríamos intentar a través de algún inicio alternativo al del sistema para volcar todo el contenido de la memoria en disco, para analizarlo con detenimiento con posterioridad. Quizás no podamos acceder a primera instancia al sistema, pero si podemos iniciar un segundo sistema operativo o alguna herramienta que nos permita realizar la tarea de volcar la memoria, es posible que en la memoria volcada esté aun residente algunas de las keys buscadas.
Se podría proteger así mismo el sistema para evitar incluso el acceso a un inicio alternativo por medio de un HDD externo, USB… pero aun así no sería algo definitivo, dado que siempre se podrían extraer físicamente (cuando sea posible claro) la RAM del sistema e implantarla en otro equipo o analizador para poder volcar su contenido.
Las únicas defensas ante este tipo de ataques es tomar las precauciones necesarias, por ejemplo jamás dejar un sistema que sea crítico conectado a la alimentación si no se está usando, usar hardware específico para almacenar las keys como por ejemplo tarjetas personales, obligar a usar PINs para proteger las keys… en fin. Aunque ningún método es fiable al 100%, al menos siempre se puede complicar la obtención. No pensar solo en un PC cuando se habla de criptografía, un movil, una PDA, una tarjeta inteligente… a fin de cuentas todos los dispositivos electrónicos funcionan de una forma muy similar: Memoria, uno o varios procesadores, registros, puertos de entrada/salida… por eso cualquier sistema que se requiera seguridad, podría implementar medidas para garantizar que cuando el sistema sea apagado las keys ya no residan de modo alguno en memoria, por ejemplo forzando el desmontaje de las unidades cifradas cuando no están en uso y técnicas similares, aunque como se ha dicho, lo mejor es simplemente no usar sistemas de suspensión S3 o de hibernación S4 en sistemas que deseamos que dispongan del mayor grado de seguridad.
Continuando con el estudio del hardware y el arranque en frío, nos topamos con la monitorización del hardware. Es evidente que cuando hablamos de Side Channel lo normal es mezclar la informática con la electrónica al más puro estilo. Dado que podemos conocer el funcionamiento exacto de un hardware o de un módulo TPM, de la memoria, del procesador… podríamos estudiar su funcionamiento electrónico en determinadas tareas, con herramientas como los osciladores, los analizadores lógicos, sensores de temperatura… es evidente que para todo ello es necesario tener acceso al hardware del sistema, tiempo y instrumentación.
Pensar en un sistema en el que las Keys sean almacenadas en un procesador criptográfico tipo TPM, y que este cuando lo cree oportuno carga la key en su propia memoria interna para ser utilizada. Imaginar que disponemos de instrumentación necesaria para “abrir” ese procesador criptográfico, que será un chip encapsulado en plástico, y conectar sus buses de datos a un analizador lógico. Una vez todo el sistema conectado y preparado, se realizará un arranque normal, pero a la par se estaría analizando toda la información que circularía por los buses de datos del módulo TPM. Si en algún momento la key viaja por los buses de datos de este, el analizador lógico será capaz de leerla. Esto mismo es aplicable a un PC, se podría conectar un analizador lógico a los buses de un PC e intentar buscar por ellos el dato deseado. La premisa es la misma, es buscar la key allí donde pueda circular.
Un método más agresivo a la monitorización del hardware sería el intentar la extracción directa. Las keys que son usadas para cualquier tipo de cifrado asimétrico suelen estar almacenadas, es lógico. Lo normal es que estén almacenadas en algún soporte extraible como una tarjeta criptográfica o en algún hardware especializado, tipo TPM. Da igual que estas estén protegidas o no por contraseña, ya que los PIN realmente lo que nos da es la llave para acceder a ella, pero de cualquier forma las keys están en dichos soportes de forma física. Si las keys están en ellas de forma física, en algún lugar de esa electrónica existirá un registro, una pequeña memoria (ya sea Flash, ROM, EEPROM…) que contiene dichos datos sensibles. Visto un todo desde fuera parece simplemente algo absurdo poder mirar ahí, pero desde un punto de vista electrónico es la mejor opción. Hay que tener en cuenta que la mayoría de las memorias ROM, EEPROM, FLash… se acceden de una forma “estandar”. Lo que sucede es que es la misma electrónica y procesadores que están en los circuitos los que es´tan diseñados para que el sistema no pueda acceder a ellos, pero no implica que no se pueda acceder a ellos manualmente. Podría ser por tanto posible acceder a los elementos hardware de dicha tarjeta criptográfica, hardware TPM… de forma que pudiésemos tener acceso a dichas memorias, y que por medio de algunos cables conectados en los puntos exactos y enviando las señales correctas a dicho hardware, este nos devolvería su contenido, revelando así los datos deseados. Es evidente que esto es tan solo la teoría, la práctica es mucha más compleja, se requiere de material especializado para ello y ni siquiera se puede decir que tenga un éxito rotundo, ya que dependerá de la electrónica, de la complejidad, de la seguridad… con la que fue dicho dispositivo creado. A fin de cuenta este tipo de Side Channel tan solo podremos verlo nosotros como teórico, aunque por supuesto es usado de forma práctica. Pensar en espionaje industrial, gobiernos, mafias…
Dejando de momento un poco el hardware concreto, ha existido una técnica sorprendente, yo la llamo análisis electromagnético. En física, cualquier paso de electrones es por un cable produce un campo eléctrico y por tanto un campo electromagnético. Ahora bien, pensemos por ejemplo en un cable de red Ethernet por el cual circula toda nuestra información. Ese flujo de información está produciendo que dicho cable ethernet esté emitiendo constantemente radiaciones electromagnéticas que podrían ser estudiadas, y a través de ellas ser capaces de conocer la información que viaja por ellos. Esta tecnología existe a día de hoy. Si bien es cierto que esto no afecta directamente a los sistemas de encriptación tal y como estamos explicando, estas técnicas podrían ser usadas de igual forma para estudiar las radiaciones electromagnéticas que proceden por ejemplo de una tarjeta criptográfica en funcionamiento, o un módulo TPM, y de este modo, como si de un analizador lógico se tratase, lograr el cometido deseado.
Por otro lado podríamos realizar un estudio analítico del consumo y el estado del hardware en las tareas de codificación/descondificación. Un procesador criptográfico o una CPU no requiere el mismo consumo energético para computar por ejemplo una key de 128 bits que para una de 192 bits. Todo este tipo de información es activamente utilizada en conjunción a otros ataques para poder lograr el fin deseado. Del mismo modo, se pueden monitorizar los estados que ocurren en el procesador, como por ejemplo si el procesador ha pasado a un estado de inactividad C6, si se ha introducido un error controlado en los datos para estudiar como se comporta el sistema… es decir, cualquier “trampa” que podamos imaginar para poder extraer cuantos más datos sea posible sobre el sistema, y con ello lograr descubrir que está circulando realmente por sus interiores, o si la key tiene que tener 4 o 5 caracteres o…
Por último, los análisis de tiempos podemos decir que son similares a los análisis de consumos, solo que en este caso se estudia sobre todo el tiempo de computación. Del mismo modo que el procesador tendrá un consumo mayor para computar una key mayor, también requerirá de más tiempo para dicha labor. Pero es más, es posible incluso que el tiempo que requiera un procesador para cifrar una key, por ejemplo: “101010″ sea diferente a la que se requiera para la key: “101011″ (se ha modificado un bit).
Se podrían estudiar estos tiempos o estados a lo mejor para ser capaz de aplicar correcciones estadísticas a ciertos algoritmos para la obtención de una clave privada desde una clave pública. Si el problema de esta es la imposibilidad de obtener la factorización, por medio de optimizaciones, cribas y otros gracias a estas técnicas, se podría diseñar para un sistema concreto un algoritmo que fuese capaz de factorizar la clave pública en un timpo razonable.
Otro posible uso sería estudiar el tiempo de la latencia de la red, de los sistemas de dos extremos que usen una conexión SSL/TLS y con ello realizar un estudio que pudiera indicarnos cual es la key privada que se está usando, dado que los tiempos, las latencias, los retrasos… todo ello puede verse afectado dependiendo de cada bit que pueda poseer la clave privada.
En Side Channel se estudian todas las posibilidades que puedan brindarnos un mayor grado de información de un sistema. Cuanta más información se pueda extraer de dicho sistema, más fácil o posible será poder atacarlo.
Para acabar, Actualmente existen técnicas para poner en jaque prácticamente cualquier tipo de cifrado o sistema de autentificación. Esto no implica que en la actualidad no exista nada seguro, simplemente no existe nada seguro al 100%, aunque si al 99.99%. Con una buena praxis y una buena educación en seguridad, un sistema informático o electrónico puede ser una bastión en toda regla frente a ataques externos.
