martes, 30 de octubre de 2007

el código indescifrable II

Hace tiempo rumiaba que la única forma totalmente segura de cifrar un archivo de 8 "letras" era con una clave de 8 "letras". Es decir, la clave tiene que ser tan larga como los datos, ya que es la única forma de que las posibilidades de descifrado sean infinitas, infinitos mensajes descifrados correctamente con parte de las infinitas claves, obteniendo textos o datos legibles entre los cuales será imposible determinar cuál es el bueno.

Algunos programas de ordenador comerciales utilizan códigos para evitar la piratería o para que el cliente pueda actualizar su producto. Estos códigos a veces se introducen a mano, y otras veces vienen proporcionados en un archivo, para mayor comodidad evitando tener que teclearlo, pues suelen ser muy largos.

Ahí está la solución: no podemos memorizar una clave de -pongamos- un millón de caracteres, ni nos cundiría en tiempo introducirla, pero podemos utilizar cualquier fichero del ordenador que sepamos que no va a alterarse como clave: un documento de texto, un ejecutable EXE, una DLL...
De este modo podemos tener claves tan enormes como el tamaño en Kb del fichero, sin necesidad de memorizar nada más que la situación y nombre de ese fichero en el disco duro.

Por supuesto esto no sustituye al password tecluscrito, sino que lo complementa. Si el intruso se hace con el algoritmo de encriptación (damos por hecho que es un crack de la informática y tiene medios y conocimientos para sacar todas las entrañas del ejecutable de nuestro programa encriptador) y sabe o sospecha que la clave está en algún fichero dentro del mismo ordenador, se lo dejamos tiradísmo: el descrifrado por fuerza bruta será mucho más sencillo que si el código fuera una clave normal y corriente, ya que el número de ficheros en un disco duro es muy limitado en comparación con las combinaciones de una clave decente: sólo tendría que atacar probando con todos los ficheros del ordenador hasta que salga el correcto. Cuando tenga el fichero, tendrá a la vez los 8 millones de bits de la clave.

Por tanto, nuestra clave se introduciría de esta manera:

PASSWORD:> C:\windows\bin\CLULSE.DLL 1a2b3c4d5e

Como vemos la clave consta de dos partes: un fichero de claves dentro del ordenador y una clave manual alfanumérica que únicamente está guardada en nuestra memoria sesuda.

Suponemos que el archivo CLULSE.DLL ocupa 2 Megas. Es un archivo que no nos sirve para nada, pero es real, quizá de un programa que no utilizamos o hemos borrado, o ese intruso al que no se le escapa ni una podría sospechar de un fichero .DLL que no tiene el encabezado de un DLL auténtico. Porque no, no vamos a esconder la llave debajo del felpudo, ni en la caja fuerte, ni al final de un pasillo repleto de robots asesinos... todo eso es ayudar al intruso a saber dónde buscar: la llave tiene que estar visible, pero sin forma de llave, y debe de estar mezclada con otros miles de objetos variopintos.
Podremos encriptar con este DLL en concreto archivos de hasta 2 megas interaccionando cada bit del archivo con cada bit del DLL sin que en ningún momento haya que reciclar datos.

El algoritmo sería muy sencillo, teniendo una clave tan larga, y además... BINARIA lo que aumenta la complejidad al no restringirla a los caracteres manejados por los humanos, que se reducen a los introducibles cómodamente desde un teclado... bastaría con simples operaciones booleanas de bit de forma secuencial, ganando en velocidad de encriptado y desencriptado.

Por ejemplo:
Tomamos en primer bit del fichero de clave y hacemos una operación de conjunción (AND), disyunción (OR) o exclusión (XOR) con el primero de la clave manual complementaria; el bit obtenido lo llamaremos X. Con X volvemos a hacer otra operación lógica con el primer bit del fichero a encriptar o desencriptar... y vamos grabando.
Ahora volvemos a aplicar lo mismo pero partiendo ésta vez de el anterior valor de X: operación con el siguiente bit del fichero de clave, su resultado lo operamos con el siguiente bit de la clave manual, y obtenemos un nuevo X para operar con el bit que venga del fichero a encriptar.

Los bits de la clave manual se terminarán rápido, porque será una palabra corta asequible para nuestra memoria y el tiempo que requiere teclearla, y tendremos que volver a recliclarla desde el principio; pero ahí seguirá de fondo el fichero de clave con sus millones de bits para evitar que se repitan patrones.

Pegas:
1. Como siempre la máxima debilidad es que en un momento dado el documento sin desencriptar residirá en el disco duro y, aunque se borre, existen programas para recuperar datos borrados del disco duro.
  • Solución 1: También existen programas para borrar lo que ya está borrado, definitivamente.
  • Solución 2: Complementaria a la anterior: el propio programa de encriptado-desencriptado permitirá visualizar -e incluso redactar- el documento guardándolo en la RAM (memoria que se desvanece al apagar el ordenador), no usando jamás el disco duro para soportar ninguno de los datos delicados. Podría ser un procesador de texto -para el caso de encriptaciónd e textos- con el codificador integrado. Esto es lo que tengo hecho desde hace años: aprovechando las fuentes libres de un procesador de textos en C, añadí el encriptador y los menús pertinentes. De este modo escribo en el editor y guardo el archivo ya encriptado en el disco duro, el texto desencriptado nunca pasa por el disco duro... en teoría... porque tampoco tengo la certeza de que el programa no se valga del disco duro en algún momento para ficheros temporales. En la medida de que el procesador se basa en windows... esas cosas las controlará el propio sistema operativo más allá del código en C del programa. Mis conocimientos no llegan hasta tanto, de hecho yo no sería capaz de programar el propio procesador de textos por mí mismo si no es copiando y pegando código.

2. La posibilidad de que el sistema operativo marque la fecha de última utilización en el archivo del fichero de claves, dando al intruso pistas sobre qué ficheros del disco duro tienen más probabilidad de ser los que busca.

6 comentarios:

humo dijo...

Ya he venido tres veces, pero soy incapaz - o sea, de letras - de entender un post tan técnico, así que volveré en unos días...

Herel dijo...

Pues de eso va esto: de letras, de encriptar letras ;D

Zereth dijo...

Es otra opción, dejar una detallada explicación al inicio de tu pc dando instrucciones de como obtener los archivos más interesantes.

Supongo que la mayoría desistiría de ver que no, no contienes el secreto para hacerlos inmensamente ricos, vaya, ni siquiera una anécdota que satisfaga su morbo.

:D

Besos

Herel dijo...

Bueno, depende de para quien puede ser importante o no.
Es como si dejas tu diario en la mesilla de noche para que nadie lo vea como un trofeo... pero claro, si sabes que lo va a poder leer todo el mundo, no escribirás muchas cosas.

Edu dijo...

Que pasaaaa, Herel, ¡cuantos tiempos! :-)

Yo haría algunas puntualizaciones sobre lo que comentas:

1. La única forma totalmente segura de cifrar un archivo de 8 "letras" es con una clave de 8 "letras" QUE SEAN TOTAL Y REALMENTE ALEATORIAS (que son las que son un coñazo para recordar). Ya que si en la práctica utilizas como clave alguna palabra (quien dice palabra dice frase) de diccionario o una combinación numérica o alfanumérica previsible, la fuerza bruta puede dar sus frutos. Este mismo problema puede hacer que una clave manual añadida al método del fichero no sea tan eficaz si está mal elegida.

2. Lo de utilizar ficheros como una gran clave es muy buena idea, pero hay que tener en cuenta que en realidad el contenido de un fichero no es aleatorio ni mucho menos, sino que siguen determinadas estructuras: los ejecutables se componen de instrucciones que han de ser válidas y coherentes para el procesador, los ficheros de imagen tienen una cabecera y unos datos que siguen una determinada estructura, los de vídeo otra diferente... Ante la inmensidad de valores aleatorios válidos que tendrían un número realmente aleatorio, un fichero no presenta tanta (pero bueno, supongo yo que de cualquier manera dejaría a un montón de superordenadores trabajando unos cuantos años).

3. En cuanto al hecho de que el texto desencriptado esté sólo en RAM y nunca en disco, no tiene porque ser así: Todo sistema operativo actual utiliza la técnica de memoria virtual para incrementar su capacidad de procesamiento y al arrancar cualquier programa la parte de él que se prevee usar va a RAM, pero otra parte se queda en el disco duro, en uno de esos ficheros temporales. Concretamente, en Windows XP el pagefile.sys por ejemplo. Por ahí podría pasar el contenido en claro del texto desencriptado y leerse de allí.

4. Un consultor de seguridad que conozco (hermano de nuestro compañero de viaje MT) comentaba algo así como que el no se fía de que un fichero está totalmente borrado hasta que no se han sobreescrito sobre él datos realmente aleatorios unas cuantas veces. Que si únicamente se borra con todo 0 o 1 como hacen muchos programas aún es posible encontrar minitensiones residuales que dan pistas sobre lo que contuvo algún día (aunque hay que ser paranoico para hacer todo esto :-DDD :-DDD)

Herel dijo...

De acuerdo con todo, Edu, de hecho en lo del sistema operativo no estaba seguro, porque ahora todas ess cosas son invisibles al usuario. Y más con internet, que no sabes a dónde puede estar enviando secretamente tus datos :DD
Una vez probé un programa residente -¿se sigue diciendo residente?- que iba grabando en un fichero todas las pulsaciones del teclado. Vamos, ideal para pillar paswords en ordenadores ajenos. Aunque claro, esos programas son en sí un riesgo, tú espías y el creador del programa mismamente puede instalar un "back hole" para espiarte lo que tú espías, y a tí de paso.

¡Juer, el hermano del Mr. T. es más desconfiado que yo!