Unidad II.

Seguridad y Programacion Seguridad Encriptacin y Autenticacin

Hash
Un hash podemos definirlo como el resultado de una funcin matemtica aplicada a una entrada arbitraria de datos, de forma que el resultado es (idealmente) asociado nicamente a la entrada dada y siempre obteniendo un resultado de longitud finita y concreta para el mismo hash. Es decir, idealmente para los hash criptogrficos sera imposible volver a obtener el mismo resultado con otros datos diferentes. La idea es poder convertir la cantidad de datos que sea en un resultado de longitud fija (fijada por el propio hash). Veamos un ejemplo muy sencillo de esto. Imaginar uan funcin hash que realiza lo siguiente sobre nmeros enteros: Hash = numero1 + numero2 + numero3. MODULO 100 En dicho ejemplo el hash se calculara sumando cada numero de entrada dado y se le realizara la operacin Mdulo 100. La operacin mdulo devuelve simplemente el resto de la divisin, y dado que el divisor es 100, el resto ser siempre un nmero entre 0 y 99:

n1 = 500 n2 = 100 -> Hash = (500+100) MOD 100 = 600 MOD 100 = 0 Hash = 0 (600/100 = 6 y resto 0) n1 = 1250 n2 = 25 n3 = 5460 Hash = (1250+25+5460) MOD 100 = 6735 MOD 100 = 35 Hash = 35 (6735/100 = 67 y resto 35) Evidentemente esta funcin hash sera un tanto absurda desde un punto de vista criptogrfico, dado que sera relativamente muy facil obtener el mismo resultado con dos entradas de datos diferentes. Pero sirve para dejar ver ms o menos de lo que estamos hablando. En este caso tan solo existen 100 posible resultados, pero se puede observar que si modificsemos cualquier nmero este podra repercutir en un resultado completamente diferente. Las funciones hash hacen ms o menos esto, aunque no con una precisin de 100 posibles valores y de una forma mucho ms eficiente, pero la idea es la misma. Pero no solo es til pensar en criptografa, una funcin Hash puede tener un valor muy importante simplemente en la deteccin de errores por ejemplo. Para que sirve esto? Tiene una gran utilidad en muchsimos campos. Podemos decir que existen tres tipos de Hash: Hash checksums, Hash CRC y Hash criptogrficos.

CheckSum

Sera el ejemplo ms bsico de Hash. El concepto apareci de la necesidad de verificar de algn modo la integridad de la transferencia de los datos. Es decir, si estos se haban transmitido de forma alguna de forma errnea. Pero como podemos verificar esto? Podemos tratar los datos de entrada de tal forma que nos de un resultado, de modo que si el resultado es diferente en el destino, los datos son erroneos. Generalmente un CheckSum es una operacin matemtica basada en sumas. El ejemplo expuesto anteriormente sera un posible ejemplo de checksum. El ejemplo de checksum ms simple es el bit de paridad. Imaginar que sea cual sea el bloque de datos de entrada, se le computa la paridad al dato, y esta se le aade al dato final. El checksums en s mismo es tan solo un bit, un cero o un uno que corresponde a la paridad del dato inicial. Cuando los datos son recibidos por el destino, el destino calcula de nuevo la paridad del bloque y la compara con la paridad recibida. Si coincide los datos son vlidos. Evidentemente este checksum tan solo previene contra 1 posible cambio de valor en uno de los bits transmitidos. Vamos a verlo con un ejemplo: Se desea transmitir la cadena Casa desde A hasta B. Imaginar que cada carcter es acompaado con un bit de paridad. Un carcter tiene un valor entre 0 y 255 segn la tabla ASCII, es decir, un carcter ocupa 1Byte de datos (8 bits). El carcter C equivale al cdigo ASCII x43 (43 en hexadecimal), lo que en binario equivale a 01000011: C -> 01000011 -> Se aplica Paridad Par por ejemplo (Hay nmero par de unos? si es asi el resultado es cero, de lo contrario es uno) -> 3 Unos, es impar, bit de paridad par = 1 C -> 01000011 + bit de paridad -> Datos transmitidos: 010000111 De este modo, el destino tan solo tiene que tomar los primeros 8 bits y realizar la misma operacin. Si el resultado coincide no hay error o no se ha podido detectar. Si no coincide se ha producido un error y los datos no puede tomarse como vlidos. En este caso caso, tan solo se podra detectar con un bit un nmero impar de errores: 1, 3, 5 dado que si se produce un nmero par de errores el bit de paridad no cambiara.

Evidentemente existen Checksums ms eficientes, aunque todo depende del uso que se le haga. En cambio todos los das tratamos con este tipo de sistemas, y no hay que profundizar siquiera en la informtica. En la mayora de datos personales que puedan ser sensibles, suele existir un carcter o caracteres de control que verifican que los datos introducidos son vlidos. Por ejemplo la letra de nuestro DNI no es ms que un checksum, que se obtiene aplicando un mdulo 23 al nmero de la divisin. Al resultado (entre 0 y 22), se le asigna una letra ya espeificada. Por ejemplo, el Cero es la letra T, el tres es la letra A de tal forma que si damos o introducimos nuestro DNI de forma incorrecta, es posible verificarlo simplemente comprobando la letra proporcionada y ver si coincide con la que debera de ser. A este ejemplo se le suman los carcter de control de los nmeros de cuenta corriente, de otros datos del DNI, nmero de la seguridad social es una forma simple y efectiva de detectar con prontitud cualquier error en los datos tomados. Otro uso increblemente extendido es en la verificacin de datos en s mismos, no solo en la transferencia de estos. As por ejemplo, si se quiere disponer de algn tipo de archivo que

pueda tener datos relativamente sensibles como bios, firmwares, datos personales lo normal es ir aplicando checksums a determinadas partes del archivo incrustando este mismo en las diferentes partes del archivo. De este modo, el software a medida que va procesando el archivo puede ir verificando cada bloque para asegurarse de que el archivo es confiable. Pensar en una bios que se quiere actualizar y por cualquier motivo existe un error en uno solo de sus bits. Es suficiente para que el PC no arranque. Para evitar esto, se distribuye por toda la bios checksums que van verificando bloques menores, Su uso no obstante se ha ido reduciendo con la aparicin de los Hash CRC, los cuales suelen realizar operaciones similares pero de una forma mucho ms efectiva. No obstante para pequeos bloques de datos o comprobaciones sencillas suele ser ms fcil y barato de implementar Checksums. Entre los Checksums ms habituales encontramos Sum8, Sum16, Sum32 o Sum64.

CRC Se traduce como comprobacin de redundancia cclica. Su objetivo y uso es muy similar al del checksum, de tal modo que no es raro ver lugares en los cuales el nombre de CRC no es ms que un tipo de checksum. La necesidad de la verificacin de los datos es algo de suma importancia, siendo quizs su mximo exponente la firma digital, de la cual ya hablaremos de ella. Pero no solo la deteccin de errores es necesaria, a veces es necesaria tambin la correccin de estos. Aunque un checksum puede usarse para esto, es ms normal ver este tipo de correctores como CRC. Aun as, los sistemas de correccin de errores suelen ser costosos en cuanto a rendimiento, precio, implementacin tanto que normalmente no compensa, y es mucho ms eficiente simplemente un buen sistema de deteccin, y si la deteccin es erronea simplemente se retransmiten de nuevo los datos. Si bien los checksums pueden ser una herramienta muy extendida dentro de los propios archivos, los CRC suelen ser usado de forma mucho ms extensa en la transmisin de datos, aplicado normalmente a bloques de datos de un tamao mayor. El peor escenario que puede darse en una transmisin de datos o en un error en un archivo, es que este no pueda detectarse, haciendo que los datos sean enviados o procesados como legtimos. Y es esto lo que se debe de evitar a cualquier precio. Por ello, los CRC son usados intensamente en la transmisin de datos sobre internet, telefona y por supuesto en la integridad de los datos en un disco duro, CD, pendrive y otros dispositivos. Cuando hablo aqu de integridad no me estoy refiriendo a sistemas de checksums que puedan estar implementados en la misma estructura del archivo, sino sistemas de ingreidad que poseen los propios dispositivos. Gracias a la integracin hardware y la simplicidad de como opera un CRC (la mayora de ellos), la gran mayora de nuestro hardware implementa funciones CRC en l mismo, sin necesidad de un software. Es decir todo el proceso es transparente a nosotros. El funcionamiento de un CRC es simple. A un bloque de entrada se le aade primero los bits correspondiente al CRC, y el nuevo bloque se divide por un polinomio preestablecido. El resto de dicha divisin binaria ser el CRC. Dicho CRC se aade al bloque original y se

retransmite. El destino tomar el bloque y lo dividir por el polinomio generador (que ser el mismo que us el emisor). Si el resto es cero, no hay error de transmisin, o al menos no hay error detectable. La eficiencia radica por lo cual en el polinomio generador usado y evidentemente en el nmero de bits usados para el CRC. El caso ms simple de CRC sera el bit de paridad, que correspondera a un bit de CRC tan solo, y el polinomio generador sera X + 1, el cual se traducira como 11 como divisor del mensaje de entrada. Un polinomio generador tal como X5+X4+X+3 se traducira por lo tanto como 110011 y se tendra un CRC de 6 bits. Aun en los CRC-32, no se puede considerar CRC un hash seguro, no est pensado como resultado nico de una posible entrada ni como sistema de ocultacin o cifrado de datos, sino como un sistema robusto de deteccin de errores, y francamente, hace su trabajo a la perfeccin. Gracias a este tipo de funciones hash, a da de hoy disponemos de medios de comunicacin fiables y con una gran tolerancia a fallos. Que no apreciemos este tipo de tecnologas, no implica que las estemos usando constantemente. Para hacernos una idea de la eficiencia de los CRC, un CRC-16 tienes el siguiente ndice de deteccin:

Deteccin del 100% de errores simples (errores que afectan tan solo a un bit) Deteccin del 100% de errores dobles de bits adyacentes (Si dos bits consecutivos son errneos) Deteccin del 100% de los errores para datos de hasta 16 bits. Deteccin del 100% de todos los errores de dos bits que no estn separados uno del otro exactamente a 216-1 bits Para el resto de posibles errores, se establece tan solo una no deteccin en un fallo de cada 216

Es decir, un cRC-16 sera capaz de detectar aproximadamente el 99.995% de todos los errores. Esto es mucho o es poco? Esto equivale a que cada 20.000 errores, uno no se detecta. Teniendo en cuenta las comunicaciones ultrarpidas de hoy en da, la cantidad de informacin que es manejada en segundos es simplemente impresionante, por lo cual podemos afirmar que de cuando en cuando efectamente aparecern errores no detectados. Esto se subsana tambin gracias a la fiabilidad cada vez mayor de las propias redes, con menos ruido, con mejores equipos Los CRC ms comunes son CRC8, CRC16, CRC32 aunque si se desea ver una lista de ellos con sus polinomios generadores tan solo hay que acudir a la Wikipedia, por ejemplo.

Criptografa En realidad son los Hash que nos van a interesar a nosotros. Este tipo de hash se usan ya no solo como detectores de errores (que pueden valer para ello tambin). Este tipo de Hash, al igual que los que hemos visto, es u procedimiento determinista que devolver un resultado de una longitud fija. Pero a diferencia de los CRC o checksums en los que su objetivo principal es la deteccin de errores, la funcin de un hash criptogrfico va mucho ms all:

La imposibilidad de poder encontrar una cadena (un bloque de datos) cuyo resultado sea un hash dado. La imposibilidad de modificacin de la cadena inicial, sin modificar el hash. La imposibilidad de encontrar una segunda cadena que verifique un hash de otra cadena. Un hash que sea computacionalmente eficiente y facil de implementar.

Hay que comprender que con imposibilidad no podemos asegurar que sea imposible, sino que el coste computacional para ello sera tan ingente que de ninguna forma sera factible. Esto evidentemente no es ms que la teora, en la prctica todo no es tan simple. A diferencia de los CRC o los checksums que pueden comprenderse sin muchas nociones de matemticas y parten de unos conceptos simples, los hash criptogrficos son bastante ms complicado de comprender (las matemticas escondidas detrs de ellos). Cada algoritmo hash tiene sus propios fundamentos, basados en premisas diferentes, siempre intentando cumplir cada una de las premisas dadas. No obstante podemos citar los Hash criptogrficos ms usados a da de hoy, como pueden ser: MD4, MD5, RIPEMD, SHA-1, SHA-256, SHA-512. Por supuesto existen muchos otros, aunque menos usados. Posiblemente a muchos algunas de esos nombres les sea conocido. Al cumplir las premisas citadas, los Hash criptogrficos suelen ser usados de forma intensiva en los siguientes campos:

Comprobaciones de archivos Firmas digitales Tablas Hash Integridad de un mensaje/contenido

Dado que un Hash puede ser usado para detectar errores en el envo y/o recepcin de los datos, un Hash criptogrfico puede ejercer funcin de Comprobador de archivos. Mientras que CRC o checksum suelen aplicarse normalmente a porciones de cdigo, tramas en las comunicaciones, pequeos detectores este tipo de hash en realidad no se disean como correctores de errores o para que el contenido sea reenviado si no es correcto. Este tipo de Hash se suelen aplicar sobre un archivo completo (o conjunto de ellos). Para estos Hash, no importa lo grande o pequeo que sea el dato a verificar (pensado especialmente para grandes cantidades de datos en comparacin con CRC o checksum claro est). Comprender su funcin en este caso es simple. Al contenido original se le apluca un Hash criptogrfico el cual se adjunta al software/archivo original. Cuando el receptor lo descarga, tiene acceso a l solo tiene que calcular el mismo el mismo Hash y comprobarlo con el Hash que ha sido descargado desde la fuenta original. La idea es que sl el hash es el mismo, tenemos la certeza de que el archivo no se ha corrompido por el envo y la recepcin ha sido satisfactoria. Por un principio similar, se puede verificar la integridad y veracidad de dicho archivo, que no ha sido modificado por nadie, que es legtimo. Podemos afirmar esto dada las propiedades ya vistas de este tipo de Hash: La imposibilidad de poder encontrar o crear otro archivo que pudiese coincidir con el hash del archivo original, y por otro lado no

sera posible modificar el contenido del archivo sin alterar el hash que se calculara en el destino. Ver esto es muy fcil con algunos ejemplos. Tan solo tenemos que buscar un software que sea distribuido por razones de seguridad con su hash. En este caso vamos a usar por ejemplo la imagen de Windows 7 x64 Ultimate ENG. Imaginad que no te quieres molestar en ir a la tienda y encuentras un vendedor supuestamente autorizado que te permite descargar una copia de la imagen de Windows 7 (la misma que he expuesto ahi). Pero claro quieres asegurarte de que la imagen sea legtima, y no sea una imagen modificada a la que se le haya puesto una activacin o algn crack para poder instalarla. Solucin? Conocer el Hash de la imagen legtima. Me pongo en contacto con Microsoft o investigo un poco para conocer el Hash de la imagen original y lo que obtengo es lo siguiente: Windows 7 Ultimate x64 ENG: 7600.16385.090713-1255_x64fre_client_enus_Retail_Ultimate-GRMCULXFRER_EN_DVD.ISO MD5: F43D22E4FB07BF617D573ACD8785C028 SHA-1: 326327CC2FF9F05379F5058C41BE6BC5E004BAA7 Lo nico que se debe de hacer en este caso es verificar si los valores que yo obtengo al calcular el hash son esos o difieren. En teora con el clculo de uno de ellos es suficiente. Para hacer esto se puede usar por ejemplo la utilidad md5sum sha1sum: E:\Windows 7 Ultimate Final (EN-DE-JP-AR)>md5sum 7600.16385.0907131255_x64fre_client_en-us_Retail_Ultimate-GRMCULXFRER_EN_DVD.iso f43d22e4fb07bf617d573acd8785c028 *7600.16385.090713-1255_x64fre_client_enus_Retail_Ultimate-GRMCULXFRER_EN_DVD.iso E:\Windows 7 Ultimate Final (EN-DE-JP-AR)>sha1sum 7600.16385.0907131255_x64fre_client_en-us_Retail_Ultimate-GRMCULXFRER_EN_DVD.iso 326327cc2ff9f05379f5058c41be6bc5e004baa7 *7600.16385.0907131255_x64fre_client_en-us_Retail_Ultimate-GRMCULXFRER_EN_DVD.iso Si dicha imagen hubiese sufrido cualquier tipo de modificacin el resultado sera muy diferente. Por ejemplo, si a la imagen le modifico simplemente el primer bit (que es un cero, y lo establezco a uno con un editor hexadecimal) y le recalculo el hash MD5, esto es lo que obtengo: 4420bc0022a2ca8a361111b7a4d24ea7 Es decir, modificando tan solo un bit, el hash es completamente diferente. Por los mismos principios sera en la prctica imposible modificar aleatoriamente (o a conciencia) los bits de forma que pudiese obtener el mismo hash. Y he dicho en la prctica por una razn concreta que ahora veremos. Vamos a suponer el caso concreto del Hash MD5. El Hash MD5 es un hash de 128 bits, lo que significa que cualquier contenido al que se le aplique este hash, se obtendr una salida

de 128 bits, una cadena de 32 caracteres hexadecimales. Es decir, sin entender siquiera de paradojas o estadstica, podramos afirmar que podramos obtener un mximo de 2128 posibles hash. Esto es un nmero un tanto ingente, tanto que posiblemente una mente no es capaz de cuantificar, hablamos de 3.4 * 1038 es decir 34 con 37 ceros a su derecha. Pero aun cuando este nmero es mentalmente imposible de imaginar, si es posible de imaginar que en el peor de los casos, cada ese nmero de hash calculados estos se volvern a repetir, lo cual implica evidentemente que sera tericamente posible encontrar dos archivos exactamente con el mismo hash. Esta afirmacin en realidad no rompe los esquemas vistos, dado que no se rompe la veracidad al decir que es improbable modificar un archivo para obtener un hash concreto o encontrar ese segundo archivo que verifique dicho hash. Aunque tericamente esto es posible, aun cuando solo fuese de forma estadstica. Este es por tanto uno de los principales problemas de los hash criptogrficos, y a esto se le llama colisin. Al margen de lo bueno o malo que sea el Hash, estadsticamente es posible encontrar dos hash iguales. En este caso concreto visto, aunque es posible tericamente, en la prctica si el Hash est bien diseado sera imprcticable. Cuanto tiempo necesitara un PC en ser capaz de encontrar una colisin? Pues haciendo nmeros muy por encima 15 * 1010 aos en el supuesto de que toda la poblacin mundial tenga un procesador de 4 ncleos trabajando al mismo tiempo en la misma tarea 24 horas al da. Es decir en el peor de los casos sera virtualmente imposible. El problema es que esta lgica no es as. Cuando se habla de una colisin en un hash hay que recordar la llamada Paradoja del cumpleaos. Cabe sealar de nuevo que es muy diferente encontrar un contenido que verifique un hash concreto a encontrar dos contenidos disferentes que posean un mismo hash. Lo segundo es una colisin. Es cierto que para el primer caso la probabilidad sera la ya citada, pero no para el segundo caso, y aqu aparece lo que puede parecer increible: La paradoja del cumpleaos establece que en una habitacin con 23 personas, existe un 50% de probabilidad de que dos personas cumplan aos el mismo da, y si fuesen 60 personas la probabilidad sera del 99%. No hay truco, simplemente se busca una coincidencia entre cualquiera de las 23 personas, no una coincidencia concreta dentro de las 22 restantes. Teniendo esto en cuenta, MD5 posee tan solo 232 posibilidades de encontrar una colisin. Es decir, 4294967296 hash calculados de 4294967296 archivos aleatorios, estadsticamente debera de existir alguna colisin, es decir, dos archivos diferentes que poseen el mismo hash. Y es evidente que este nmero si que es comprensible y relativamente bajo, dado que un PC normal podra generar colisiones de hash MD5 con relativa facilidad, y esto comenzara a invalidar los puntos en los que se asienta un Hash criptogrfico. Es por esto que MD5 ha dejado de considerarse un Hash seguro, y es solo cuestin de tiempo que quede en desuso, a favor de otros Hash ms seguros. En teora cualquier Hash debera de presentar posibilidad de Colisin, aunque es evidente que si esta probabilidad es computacionalmente imposible, podemos afirmar que no existe colisin (aunque tericamente exista). Para tener presente esto, pensar que al Hash MD4 es posible encontrarle colisiones con tan solo en 256 hash. A raiz de las Colisiones, aparecieron las primeras herramientas que han empezado a romper del todo el Hash MD5. A da de hoy existen herramientas capaces de generar dos

programas diferentes que satisfagan el mismo Hash MD5, con lo que se rompe la seguridad de MD5 para la verificacin de integridad y comprobacin de un contenido. Es evidente que esto tiene matices. A da de hoy continua siendo imposible generar un contenido nuevo que satisfaga un hash buscado (lo cual rompera de forma definitiva el Hash). Pero en cambio si es posible producir dos archivos o dos contenidos que satisface el mismo hash. Esto qued de manifiesto por el doctor Xiaoyun Wang, el cual incluso liber el cdigo de una aplicacin que es capaz de realizar esto (En la cabecera de este artculo se puede encontrar) SHA-1 es el segundo Hash ms usado a da de hoy. A diferencia de MD5 (aunque basado en sus mismos principios) es un hash de 160 bits, al cual se le ha podido establecer un ndice de colisiones de 252 en el mejor de los casos. En dicho caso el clculo de una colisin sera relativamente prctica de llevar a acabo, quizs un ao o dos aos en poder lograr encontrar dos contenidos que compartan el mismo hash. No obstante se le contina considerando seguro. SHA-2 (conocidos como SHA256 y SHA-512) funcionan de forma muy similar a SHA-1, anque en este caso producen salidas de 256 y 512 bits respectivamente. En ambos casos no se conocen colisiones posibles. Ante todo esto y dado que podemos asumir que tanto MD5 o SHA-1 son algo as como estndares, ya est en marcha el nuevo concurso que ser seleccionado como sucesor de SHA-1/SHA-2 y que posiblemente ser el prximo estandar en Hash dentro de un par de aos. Actualmente se ha comenzado la segunda ronda, y a final de este ao debera de quedar todo ms o menos finalizado. La idea es encontrar un Hash ms seguro y que sea muy eficiente su clculo ,es decir la velocidad con la que se pueda calcular el hash a un contenido. Se puede acceder a una lista de todos los candidatos de la segunda ronda en la web oficial del NIST (Instituto nacional de estndares y tecnologa)

El ltimo uso que deberamos explicar son las Tablas Hash. Antes de entrar en detalle sobre este tipo de prcticas sera ms correcto hablar antes de la Sal o Salt (en ingls). Hasta ahora hemos visto funciones de los Hash criptogrficos para comprobar la integridad de los archivos, pero que sucede si queremos usar un Hash como una especie de encriptador de contenido? Esto podra no tener mucho sentido dado que cualquier persona puede calcular un hash MD5 por ejemplo a cualquier entrada pero en cambio no es posible partir del hash para obtener el contenido. Esto adquiere mucha ms relevancia cuando se usan un hash para proteger detrs de l un contenido pequeo como un nombre de usuario o una contrasea, y es aqu donde aparece el trmino y la idea de Salt. Salt es un apndice que se aade a una cadena de entrada para generar un Hash no intuituvo Dentro de la web, las cookies y otros contenidos que puedan ser sensibles de cara al exterior como nombres y contraseas puede ser sometido a un hash criptogrfico para esconder su significado original. Esto nos dar como resultado una salida nica, con lo que se podra usar dicha salida como contrasea y nombre del usuario de cara a un servidor, en vez del texto plano. Esto incrementa de forma exponencial la seguridad de cualquier

base de datos o sistema de control de acceso. Pero como hemos dicho la utilidad de esto podra ser relativa. Vamos a ver esto con 3 ejemplos que ilustrarn la eficacia o no eficacia de un Hash para estos procesos, as como la implicacin de Salt: Imaginemos que hemos robado un archivo que guarda las credenciales de acceso a una importante base de datos. Imaginemos que dichas credenciales pueden ser almacenadas en dicho archivo como texto plano, MD5 y MD5+Salt. Si abrimos ese documento encontraramos esto para cada una de las opciones: 1. Nombre: Theliel Contrasea: perico 2. Nombre: 5A04B2D961488CDA31CD065F259783BE DFE483413E24A5B1506389D36EBFD05C 3. Nombre: 217B11413677EE9D4806967515D66607 8E50E5A474DDAF3BC370F87DD97EC7F0 Contrasea:

Contrasea:

En el primer caso, es evidente que si est configurado como texto plano, las credenciales sern tomadas de forma directa y rpidamente podremos acceder a la base de datos. En el segundo caso no obstante n oparece que sea posible descifrar absolutamente nada pero que pasara si hacemos uso de la inteligencia? Podemos intuir que es un hash, y si buscamos informacin del sistema podemos incluso conocer que se trata de un Hash MD5. No podemos revertir el MD5 (a priori), pero en cambio si podemos presuponer el nombre de usuario y ver si hay una coincidencia con el hash que tenemos. Dado que el atacante es listo, comenzara por cotejar en un diccionario que ya tiene el hash. Su diccionario no es ms que una lista precalculada con quizs millones de posibles nombres de usuarios a los que ya se les ha calculado el hash correspondiente. Si el hash se encuentra en su diccionario, obtendr de forma automtica le nombre de usuario. Esto mismo se puede aplicar a la contrasea. Que usuarios se probarn primero? Admin, admin, theliel, Theliel y en este caso, el diccionario encontrara que dicho hash corresponde a la palabra Theliel. En caso de la contrasea es exactamente igual, si la palabra o frase empleada en la contrasea existe en su diccionario, obtendr directamente la contrasea buscada. Es por ello que siempre es importante tener una contrasea alfanumrica de una longitud decente. En el tercer caso la cosa es ms complicada. El atacante agotara todos sus diccionarios y no lograra encontrar el hash deseado. Por qu? Porque lo que no sabe el atacante es que el programa que codific el hash us una Salt, un trozo de datos que simplemente aadi al final del usuario y la contrasea. As si el usuario escribi el nombre de usuario: Theliel, el servidor jams lo tom como tal, sino que automticamente le aadi el Salt TATA (en este caso). Es decir, de cara al servidor cualquier dato introducido es concatenado con TATA. As, el servidor no calculara el hash de Theliel o de perico (la contrasea), sino de ThelielTATA y pericoTATA. dicha modificacin es seguro que no aparecer en su diccionario. La nica opcin del atacante es conocer la Salt usada por dicho servidor, y crear as un programa que automatice el proceso, recalculando todos los hash de su diccionario con la Salt aplicada y as con suerte obtener algn resultado. Esto lo trataremos mejor cuando se vean las diferentes tcnicas para romper la seguridad.

Pero volvamos a las tablas Hash. Hemos explicado que la Salt o la importancia que puede tener un hash para esconder unos datos, pero qu es una tabla hash? Dado que el ndice de colisiones es relativamente alto, podemos presuponer que no ser posible dar la casualidad de tener a dos nombres de usuarios que compartan el mismo hash. Si esto es cierto, para un servidor es mucho ms seguro no guardar jamas en sus bases de datos el usuario o la contrasea como tal, solo sus Hash. Al introducir los datos el usuario, son sus hash los que alcanzan el servidor y este simplemente tiene que cotejar dicho hash (el usuario) en su base de datos para comprobar si existe una coincidencia. Si existe tal coincidencia verificar el hash de la contrasea con el hash de contrasea ya almacenado. De este modo nuestros datos de sesin no seran jams enviados como tales. Pero la utilidad de las tablas de hash radica no en la seguridad (que por supuesto tambin lo es) sino su eficiencia. Hemos dicho que el servidor debera de verificar si el hash de nombre de usuario existe en su base de datos. Pero como hace esto? Si nuestra base de datos posee 100 registros, en el peor de los casos la base de datos debera de hacer 100 comprobaciones, para acabar en el ltimo registro que sera el que coincidiese con el hash del usuario introducido. Pero aun, si el usuario introducido no se encontrase en la propia base de datos, esta la habra recorrido entera buscando una coincidencia. Este proceso sera muy costoso para los servidores. Ahora bien, partimos de la premisa que el ndice de colisin de un hash MD5 es relativamente alta, 4 mil millones aproximadamente. Podramos calcularle simplemente el mdulo a dicho Hash (en funcin del nmero de ndices que tengamos en la base de datos), el resultado sera un nmero de 1 a X, siendo X el nmero de entradas posibles en nuestra base de datos. Es decir, pongamos que nuestra base de datos tiene 100 registros insertados y tiene una capacidad mxima de 997 (por ser un nmero primo). Es decir, se aplicara la operacin mdulo 997 a cada hash de entrada. Esto convertira todos los hash de entrada en un nmero que ira desde el 0 al 996. Este nmero s podra ser usado como ndice, luego el acceso al registro en la base de datos sera inmediato. Por razones de precisin, usar un nmero de 128 bits no es aconsejable, lo normal es acotar este nmero a una resolucin de 64bits, tomando por ello los 64 bits primeros del hash o los 64 bits ltimos de este. En el ejemplo anterior, al Hash Theliel se le aplicara mdulo 997, y el resultado sera: 5A04B2D961488CDA31CD065F259783BE -> 5A04B2D961488CDA MOD 997 = 763. Es decir, que el nombre de usuario Theliel sera convertido al ndice 763 en la base de datos. De este modo, al introducir Theliel en el navegador, se calculara el Hash, en el servidor se truncara y dara como resultado un ndice. Con este ndice el acceso a la base de datos sera directo, Acceso a elemento 763. Asociado a dicho ndice se podra encontrar por ejemplo el hash de la contrasea y se procedera a realizar una simple comparacin, si los dos hash coinciden se obtiene el acceso. Esto evidentemente multiplica exponencialmente la posibilidad de una colisin, dado que el espacio disponible ahora es de tan solo 997 elementos. Como hemos dicho la posibilidad de colisin depender en gran medida de la ocupacin del espacio disponible. Por la paradoja del cumpleaos no obstante, se dara el caso que con unos 35-40 elementos introducidos la probabilidad de una colisin sera de un 50%!!. Para evitar esto se acude a tablas muco mucho mayores en relacin al indice esperado de ocupacin que se tendr. Es decir, se sacrifica espacio en post de velocidad. En la Wikipedia aparece un ejemplo parejo, en el que se dice que con 2500 elementos introducidos en una tabla de un milln de elementos, la

probabilidad de colisin ascendera al 95%. Que hacer en caso de colisin? Primero evitarlas, ya sean con grandes tablas o con crecimiento dinmico de estas. Por otro lado asumir que es posible que exista una colisin, y disear el sistema de forma que ante una colisin sea necesaria una segunda bsqueda en los registros afectados para determinar el destino final.

Cifrado de datos
Este no es un trmino nuevo, y desde tiempos inmemorables es algo que se ha ido haciendo de un modo u otro. Y es que seamos honestos no nos suele gustar la idea de que puedan invadir nuestra intimidad o interceptar cartas, mensajes, ideas que van hacia otra persona. Evidentemente esto toma una importancia mayscula cuando esta informacin es sensible o de suma importancia. Quzs el primer gran ejemplo de criptografa en el mbito de las comunicaciones fue sin duda la mquina Enigma. Para quien no lo sepa, la mquina Enigma fue un dispositivo similar a una mquina de escribir diseada all por los aos 30, siendo famosa por ser usada por los Alemanes durante la Segunda Guerra Mundial. Era un dispositivo creado con inteligencia. Digamos que posea tres discos con 26 posiciones cada uno. En cada una de esas posiciones se mapeaba una letra. Cada letra de cada disco a su vez se encontraba conectada con el disco vecino, y dependiendo de la posicin inicial de cada uno de los discos, la letra era mapeada de disco en disco en una o en otra. Se diseaba de tal modo que al presionar una tecla de la mquina, esta quedaba asociada con una letra mapeada del primer disco. En el primer disco la letra se mapeaba a la letra de salida del primer disco (que no corresponda a la de entrada) y en dicha salida se conectaba el segundo disco. El segundo disco tomaba de entrada la salida del primer disco e igualmente que como haca este, internamente esa letra de entrada la mapeaba a la salida. El tercer disco haca lo propio, tomaba la letra de salida del segundo y segn su posicin en dicho momento la transformaba en otra diferente a su salida. Despues de todo esto, un 4 disco (no obligatorio) haca que existiese un camino de retorno, de forma que se pasase de nuevo por el tercer disco, despues por el segundo y despus por el primero. La salida se conectaba a una bombilla que indicaba la letra codificada. Para evitar separaciones de palabra, todo el mensaje era enviado sin espacios. Posiblemente fue la primera mquina seria para cifrar comunicaciones. Hay que decir que, segn dicen, gracias a que la alianza fue capaz de desencriptar la mayora de las comunicaciones de los alemanes (gracias a que pudieron romper en gran medida el sistema de Enigma) la guerra dur dos aos menos de lo que podra haberse alargado. Un buen ejemplo sin duda alguna de criptologa.

Para nosotros es cosa del pasado. Vivimos en un mundo digital y un mundo en el que las comunicaciones juegan un papel a da de hoy imprescindible. Por lo tanto es de sentido comn que existan sistemas que podamos considerar seguros tanto para almacenar datos de forma protegida como para ser capaces de crear canales seguros de comunicacin entre dos puntos cualquieras del mundo. Precisamente porque las comunicaciones se han convertido en algo imprescindible y de uso constante, no podemos hacer odos sordos y pensar errneamente que nuestros datos no son de la importancia de nadie. Dado que los canales de los que hacemos uso son pblicos, nuestra informacin, nuestros datos estn expuestos a todos. Puede que a nadie le importe que otros puedan saber en un momento dado en que blog escribe, que vean las fotos que tienen guardadas o las recetas archivadas. Pero seguro que a nadie le gustara que humeen en su correo, en sus cuentas bancarias, en todo aquello que pueda ser de ndole personal. Lo que pasa es que se presupone que todo es seguro y que no existir nunca una intervencin externa y esto no es as. Como vimos con el Spoofing o como veremos en otros artcuos como el Sniffing, la intencin rara vez encaja con la realidad. Por todo ello vamos a introducirnos un poquito en los sistemas reales de proteccin que podemos encontrar a da de hoy. Y digo reales porque posblemente gracias tan solo al cifrado de datos es posible garantizar una intimidad a la cual tiene derecho todas las personas. No vamos a estudiar la mquina enigma de ningn modo, vamos a ver los dos sistemas de cifrado que disponemos en la actualidad, cada uno con sus pros y sus contras, claro est:

Cifrado Simtrico Cifrado Asimtrico

Cifrado Simtrico Un cifrado simtrico no es ms que algn sistema por el cual se encripta un contenido aplicndole una clave (o key, del ingles llave) y se desencripta usando la misma clave. Podemos pensar de un modo ms especfico en una contrasea, pero esta no es ms que una particularidad de un cifrado simtrico. Por ejemplo, la mquina enigma era un dispositivo de cifrado simtrico, en el que la key era la posicin inicial de los discos y el cableado interno que mapeaba las teclas a los discos. Se usaba por tanto la misma disposicin si se deseaba recuperar el mensaje original. En la era digital, nuestras key suelen ser lo que comunmente llamamos contraseas, aunque no todas las contraseas son para cifrar. As por ejemplo llamamos contrasea a la cadena de caracteres que debemos de teclear para poder encriptar un documento, pero tambin llamamos contrasea a la cadena de caracteres que debemos de teclear para acceder a nuestro correo, y no se usa en modo alguno para cifrar nada, solo como mtodo de control de acceso. En cualquier caso, esta key (no usaremos el termino contrasea) en los cifrados simtricos sera la misma para encriptar un dato que para desencriptarlo. Como vimos en su momento con los Hash, podramos suponer que con el cifrado simtrico lo que sucede es algo similar. A un dato de entrada se le aplica una funcin que depende de

una key para producir una salida. Pero a diferencia de los hash, la encriptacin no es un camino nico, es decir, la salida puede convertirse bit a bit exactamente igual a la entrada cuando el mensaje se desencripta. Esto implica que la funcin que sea aplicada a la entrada no ser sino una serie de modificaciones que se realizarn a los datos de entrada para ocultarlos. Esas modificaciones dependern ntegramente de una key. Segn el sistema usado por el sistema de cifrado, se puede clasificar dos tipos de cifrados simtricos: Cifrado de bloques y cifrado de flujo. Pese a que pueda ser ms o menos complicada la matemticas detrs de cada algoritmo de cifrado, no lo es tanto comprender su funcionamiento.

Primero veamos el cifrado simtrico de flujo. El cifrado de flujo se pens idealmente para aquellas tareas en las que se desea cifrar algo que se est generando en tiempo real. Es decir, en un principio pensado para las comunicaciones. Esto tiene su lgica, si deseamos encriptar un archivo de 20MB en disco por ejemplo, conocemos a priori no solo el tamao completo del archivo, sino tambin cada uno de sus byte. En cambio cuando los datos a transmitir son en tiempo real (por ejemplo) el modelo anterior no vale, tan solo podemos ir codificando pequeos fragmentos de un todo, fragmentos tan pequeos como bytes o incluso bits. Es decir, cada byte (por ejemplo) que se genera, se encripta y se enva. El fragmento enviado por tanto tiene significado propio, puesto que aunque pertenece a un todo, el mismo byte (en este caso) se desencripta directamente en el destino. Pese a la complicacin que esto pueda parecer, es relativamente simple en concepto. La idea es poder cifrar unidades mnimas de contenido sin que estas dependan de nada ms. Pero esto crea un problema Si la misma key fuese usada para todos los bytes, sin siquiera conocer la key sera muy facil atacar un cifrado en flujo, dado que las unidades codificadas son muy pequeas, sera fcil encontrar mensajes o partes de estos, patrones Para evitar esto lo que se hace con los cifrados de flujos es generar tambin un flujo constante de keys. Esto suena raro el algoritmo de cifrado simtrico de flujo aplica una serie de operaciones matemticas seguras para generar a su salida un flujo constante de bits, no predecibles claro est, que a su vez son los que son usados para cifrar a su vez el flujo de datos. Vamos a ver un ejemplo sencillo de esto aplicando posiblemente uno de los cifrados ms bsicos que existe, el cifrado XOR. XOR es una operacin lgica que dice lo siguiente: style=text-align: justify;>Si A = B => A XOR B = 0. Es decir, se puede expresar como A XOR A = 0 style=text-align: justify;>Si A != B => A XOR B = 1. Es decir, se puede expresar como A XOR 0 = A Al igual que con los hash, imaginemos una funcin tal que F (key) = Kflujo Si tenemos lo anterior en cuenta, ahora imaginemos dos flujos de datos constantes de bits:

decir, el flujo constante de datos a enviar se combina Mensaje Original: 10100111 0 1011001 mediante una operacin XOR con un flujo de Kflujo: 11001011 1 1100100 datos constantes tambin generado por una Key Mensaje Final: 10100111 1 0111101 inicial gracias a un algoritmo dado. El receptor en nuestro ejempli tan solo tendra que generar el mismo flujo de datos desde la key original y aplicar la misma operacion XOR a los datos recibidos, de ese modo el mensaje original se reconstruira. De este modo, a partir de un cifrado simple y lleno de problemas como pueda ser un cifrado XOR, se logra que sea consistente gracias al flujo constante de bits derivados de la key original. No obstante, por regla general los cifrados en flujo son mucho menos robustos que los cifrados en bloques, y estos a su vez pueden actuar como cifrados en flujos, lo que poco a poco deja a los cifrados simtricos de flujo en desuso. No obstante, a da de hoy continan siendo una fuerte columna vertebral de las comunicaciones, siendo su buque insignia el cifrado RC4. Aunque es un cifrado que ya no podramos considerar seguro dado a los ataques pertrechados hacia l con relativo xito, contina siendo un cifrado extremadamente simple de implementar y de procesar, lo que lo hace ideal para tareas en las que la seguridad a lo mejor no es crucial, pero si importante. Por ejemplo, RC4 es el cifrado que usan las redes WIFI que usan WEP, el algoritmo de cifrado es RC4, y como todos sabemos WEP es un sistema a da de hoy completamente roto. Otros ejemplos de RC4 fue su uso (cada vez menos habitual) en certificados digitales (ya veremos esto ms adelante). Y posiblemente los amantes de las redes Torrent podrn ver en muchos de sus clientes la opcin de cifrar todo mediante RC4. Como vemos, aunque no nos otorga un grado de seguridad completo, para muchas tareas es bastante til. En la actualidad existen otros cifrados de flujos ms seguros que RC4, como por ejemplo las alternativas eStream. Personalmente no creo que vuelvan a ponerse de moda los cifrados en flujos, y que se continuar con la tendencia de los cifrados en bloque.

Datos para Enviar Mensaje XOR Key Datos Enviados Es

El cifrado simtrico en bloques difiere en concepto del cifrado en flujo. En este caso no se pretende a priori cifrar bit a bit un contenido, sino aplicar a un bloque de un tamao preestablecido una serie de transformaciones (evidentemente reversibles) para dar como resultado una salida encriptada de dicho bloque. La pregunta podra estar entonces, que si dicho bloque es pequeo y el cifrado de flujos acta sobre unidades grandes, ambos conceptos podran ser iguales. Y esto es cierto. En el caso del cifrado en flujo lo importante es la forma en la que se generar el flujo de keys y el sistema que se realizar para combinar los dos flujos. Aqu el sistema es mucho ms complejo y slido normalmente. Normalmente un mensaje que se quiere cifrar es dividido en bloques (de ah su nombre) de tamaos de 64-256 bits cada uno. Lo ideal por tanto es siempre encriptar un contenido que sea cientos de veces dicho nmero, con lo que

se tendran cientos de bloques independientes. Cada bloque suele funcionar del mismo modo, las mismas operaciones que se aplican a uno se aplican a otro. No obstante, al igual que sucediese con los cifrados de flujo, lo normal es que la key original tan solo sea key del primer bloque, siendo la key del resto de ellos una key derivada ya no solo de esta, sino del contenido encriptado, lo cual hace ya de por s complicada su bsqueda. La diferencia por lo tanto entre los diferentes cifrados de bloques radicar en esas transformaciones realizadas dentro de los bloques para obtener el resultado. Normalmente, a estas transformaciones se les denominan Etapas, y no es extrao ver cifrados de bloques con varias de ellas. Por ejemplo el Cifrado AES consta de entre 10 a 14 etapas, dependiendo de la longitud de su Key. Al final de todas las etapas de cada bloque, se genera el mensaje cifrado, que en contraposicin con el cifrado de flujo, aqu normalmente cada bloque cifrado es dependiente de todo su bloque, no existe una correspondencia bit cifrado bit descifrado. Pese a que cada algoritmo es diferente, los cifrados de bloques igualmente tienen diferente modos de operacin. Cada uno de ellos no difieren por el tipo de transformaciones aplicadas, sino ms bien por las interacciones entre sus bloques. As por ejemplo, el sistema ms sencillo de cifrado por bloques sera aplicar a cada bloque una funcin matemtica tipo Fbloque(Key) = Bloque_Cifrado. Es decir, a cada bloque se le aplicara siempre la misma key de forma independiente. Este esquema se contempla, y se llama sin ir mss lejos ECB. Un paso ms all sera algo similar a lo que se ha visto con el cifrado de flujos. En este caso cada bloque no es independiente. En el modo CBC el bloque cifrado se combina mediante una operacin lgica XOR con el bloque aun sin cifrar del siguiente bloque, y el resultado ser el bloque que, ahora s, se pasar a cifrar. De este modo simple, se logra una dependencia completa de cada uno de los bloques, haciendo inviable muchos ataques criptogrficos. Aunque existen otros sistemas de funcionamiento de los cifrados de bloques, la mayora aplican el concepto explicado para CBC (Cifrado de bloques en cadena) pero en diferentes partes. Por ejemplo, se podra realizar la operacin XOR en vez de entre el bloque cifrado y el bloque siguiente sin cifrar entre el bloque sin cifrar y el bloque cifrado de un mismo bloque y realizar a continuacin otra XOR con el bloque sin cifrar siguiente, y a esto se le llamara PCBC.

Estos modos de funcionamiento que pueden parecer no tener importancia, la tienen y mucha. Un test bastante conocido para comprobar la resistencia de un sistema de cifrado frente a la posible repeticin de patrones, es la codificacin de una imagen. Una imagen suele tener patrones que se repiten constantemente, es decir, en una imagen suelen existir zonas uniformes que pueden tener el mismo contenido. Luego una imagen es un ejemplo perfecto para atacar a un cifrado. Como se realiza esto? Una imagen no son ms que puntos distribuidos uniformemente sobre toda una superficie, cada cual con un color. Si quisisemos almacenar una imagen en nuestro sistema, el mtodo ms simple sera simplemente tomar cada punto de la imagen de forma consecutiva e ir aadindolo a un

archivo binarios simplemente especificando su color. Esto se comprende mucho mejor con un ejemplo. Pensar en que tenemos una imagen de 5 x 5 pixeles, cada uno de los pixeles est codificado en RGB con 1 byte para cada canal, es decir, que cada punto se representara en una matriz de (53)x5 en la cual cada elemento constituye un byte (un valor entre 0 y 255) . Esta podra ser nuestra imagen expresada como una matriz de puntos: 128 045 135 236 002 237 112 222 012 087 158 255 000 055 099 128 045 135 236 002 237 112 222 012 087 158 255 000 055 099 128 045 135 236 002 237 112 222 012 087 158 255 000 055 099 128 045 135 236 002 237 112 222 012 087 158 255 000 055 099 128 045 135 236 002 237 112 222 012 087 158 255 000 055 099 En un archivo binario esto se almacenara simplemente un valor tras otro. Para visionar dicha matriz de puntos tan solo tendramos que conocer esta distribucin y aplicarla a la pantalla de nuestro monitor. Sabemos que es una imagen de 55 con 3 canales de color, con lo que el PC tan solo debera de tomar los valores de 3 en 3. Cada 3 valores obtendr el color de cada pixel, y su ubicacin dentro de la matriz corresponder a la ubicacin del pixel en la pantalla. Este sistema no obstante no puede aplicarse a los algoritmos de imgenes actuales como JPG, PNG, TIFF ya que estos de un modo u otro aplican compresin a las imgenes (ya sea con prdida o sin ella), y no se podra comprobar lo que queremos explicar. Podramos llamar a esto una imagen RAW, el problema de llamarlo as sera la confusin que ocasionara con las imgenes RAW de las cmaras de fotos. Visto esto, veamos la aplicacin real. Primero partiremos de una Imagen RAW Fuente creada para tal ejemplo a la que he llamado egocntricamente Theliel, Alma Oscura era muy largo para este propsito:

Evidentemente la imagen mostrada aqu no es una imagen RAW (Entendiendo RAW no como imagen de las cmaras de fotos), es una conversin a png para que el navegador pueda mostrarla. Pero que es lo que sucede cuando la codificamos con un algoritmo como AES-256 (el cual veremos ms adelante)? Para ello se ha realizado dos simples conversiones, una usando el mtodo ECB y otra usando el mtodo CBC:

La primera pertenece a la codificacin ECB, mientras que la segunda imagen corresponde a la codificacin CBC. Ambas imgenes hablan por si mismas. Si se accede a las versiones

grandes, se puede comprobar aun mejor que incluso cuando se est codificando con AES256 (un cifrado muy fuerte), cuando se realiza en ECB la imagen puede ser adivinada, incluso el texto es completamente legible. La imagen no es del todo clara, pero se puede apreciar perfectamente el contorno de la manzana de Apple. Esto nos plantea lo que a mi parecer es uno de los grandes problemas de la seguridad, y es que el problema no radica ya en encontrar sistemas que sean seguros, sino en el uso que se den de ellos. Que exista el mtodo ECB no implica que sea una buena opcin usarlo. El resultado de un cifrado en ECB de cada bloque es el mismo si el bloque a encriptar no vara. En una imagen, no es raro encontrar estos patrones, y dado que podemos representar de una forma grfica esta encriptacin, obtenemos un resultado realmente curioso, como el que hemos mostrado. En contrapartida, al usar CBC, cada bloque tenga o no tenga la misma informacin, ser codificado de forma diferente, dado que la codificacin de cada bloque depende del anterior. El resultado es una nube de pxeles de colores sin sentido alguno, quedando la imagen real completamente oculta. Los cifrados de bloques segn lo explicado, no obstante deja algunas incgnitas como que sucede cuando el contenido a cifrar no corresponde a un tamao mltiplo del tamao de bloque o que sucede con aquellos bloques que requieren de un bloque anterior (o posterior) y no lo poseen dado que son el primero o el ltimo. Respecto al primer problema, el tamao de bloque, se acude a una tcnica mas que conocida por la mayora de los programadores, el Padding. Es decir rellenar. Si los bloques son por tanto de 64bits y el ltimo bloque tan solo tiene 32, los 32 bits restantes se rellenaran. Esto hace a su vez aparecer un problema aadido la salida tendr un tamao siempre mayor que la entrada, dado que ser necesario aadir tantos bits como sea el caso para poder completar el bloque. Y el segundo problema que aparece es con que datos rellenar ese Padding, lo que produce a su vez que sea complicado esclarecer el tamao REAL del mensaje original. Para esto existen diferentes tcnicas ms o menos elaboradas, pero decir al menos que rellenarlo todo con simples carcteres null (nullo) no sera recomendado. Respecto al segundo problema, lo normal es que exista una entrada adicional a la Key y al contenido a cifrar en el sistema, que se denomina como vector de inicializacin (IV). No obstante, dado que estos vectores no pertenecen al algoritmo dado y normalmente no es dado tampoco como dato de entrada, lo normal es que la propia implementacin del algoritmo lo establezca. Otra solucin sera no usarlo o suponer que de no expresarlo, el vector de inicializacin ser una cadena de ceros. No han sido pocos los cifrados de bloques que han existido y existen. Muchos de ellos buscando siempre ser el mejor en cuanto a seguridad se refiere, otros por ser los ms rpidos, otros por ser mejores en otros fines y se lleg al absurdo de que existan un sin fin de cifrados de bloques que eran usados. Todo ello por supuesto sin contar con el secretismo. Antes se pensaba que cuanto ms secreto fuese un cifrado, ms invulnerable era. Esto pareca lgico, si nadie sabe como se implementa o como funciona, lograr desencriptarlo sera complicado. El problema no obstante es que un milln de cabezas piensan ms y mejor que unas cuantas cabezas de ingenieros que en su da crearon dicho algoritmo.

As, posiblemente el primer cifrado por bloques que lleg a convertirse en un estndar y publicado como tal fue DES (Estandar de encriptacin de datos). DES contaba con una key de 56bits, bloques de 64 bits y un total de 16 rondas. Al margen de lo seguro o no que pudiese ser, hoy por hoy sera impensable un sistema de cifrado con key de 56bits. En el peor de los casos por simple fuerza bruta seran necesarias 256 comprobaciones, y con el hardware actual sera un valor fcilmente alcanzable. En 1998 se cre un hardware barato que fue capaz de obtener una key DES por fuerza bruta en tan solo 56 horas, aunque un ao ms adelante tan solo necesit 22 horas. Esto hizo replantearse seriamente el uso de DES. Despus de esto, se comenz con el uso del sucesor de DES, llamado Triple DES, publicado en 1998 y que bsicamente era igual a DES, pero usaba un conjunto de 3 Key DES de 56 bits cada una. En algunos esquemas estas Keys eran independientes, en otros eran keys derivadas. Y aun que a da de hoy se puede considerar Triple DES como seguro, la realidad es que en 2001 fue publicado oficialmente AES. Al igual que se hiciese con los Hash SHA, el perodo de estandarizacin de AES fue de 5 aos. 5 aos en los que compitieron los mejores algoritmos de cifrado de la poca, algunos de ellos conocidos dentro del mundo de la criptografa: RC6, Serpernt, Blowfish y por supuesto el ganador: Rijndael, que pasara a ser llamado AES (Estandar avanzado de encriptacin). AES se estandariz con 3 longitudes de key diferente, as existe a da de hoy AES-128 AES-192 y AES-256, con un tamao de bloque de 128 bits. No obstante, el algoritmo original permita bloques de diferente tamaos y keys. AES a da de hoy es completamente seguro. Tal es as, que el gobierno de EEUU acept el uso de AES-256 para su uso en su material clasificado como Alto secreto y AES-128 AES-192 para su material clasificado como Secreto. Es decir actualmente y posiblemente por muchos muchos aos, AES permanecer como cifrado simtrico estandar y seguro. El como funciona AES en realidad no es tan complejo si comprendemos el funcionamiento de los cifrados de bloques. Lo nico que habra que conocer son las transformaciones que se realizan en los boques, esas 10-14 etapas que se llevan a acabo en cada bloque. En primer lugar lo que AES realiza es generar una subkey de bloque derivada de la key original e interpreta la hilera de bits del bloque (128 bits) como una matriz de 44 bytes (1 Byte son 8 bits, 4x4x8 = 128 bits). Una vez se ha creado la estructura bsica del bloque, se aplica el cifrado XOR a la matriz entre esta y la subkey de bloque generada. Una vez realizada esta operacin, se realizan una series de operaciones en la matriz, como desplazamiento de columnas, mezclado y otras operaciones no lineales. Para acabar se realiza de nuevo una operacin XOR con la subkey que corresponda (diferente a la key de la primera XOR). La matriz resultado se enva como bloque cifrado en una sucesin de bytes. Como vimos en el ejemplo anterior, AES-256 en realidad s que es extremadamente seguro, pero es necesario siempre un buen uso de dichos cifrados. Para terminar un pequeo ejemplo de un esquema de codificacin simtrica, mostrando muchos de los conceptos aqu tratados:

CrypTool 2 Beta

En el esquema se puede observar como existen tres elementos principales de entrada: El archivo a codificar llamado Original, la Key usada llamada Key y un generador aleatorio de IVs. Los bloques en azul claro corresponderan a los algoritmos de cifrado, en este caso se ha usado AES-256 ECB y CBC y DES ECB. Por ltimo los archivos de salida generados de los procesos aplicados. Se observa no obstante que para los mdulos AES no se ha usado una entrada IVs. Lo que sucede es que el vector de inicializacin en este caso sera 00000000000000000 (8 bytes). DES por el contrario requiere que se incluya, por ello se ha usado un generador aleatorio de IVs, que no es ms que un generador aleatorio de valores de 8 bytes en este caso, dado qeu DES requiere un IV de 8 bytes, es decir, del tamao de cada bloque (64 bits). Cabe destacar que para la desencriptacin del archivo cifrado DES sera necesario suministrar exactamente el mismo IVs, de lo contrario no sera posible recuperar el archivo original. Para esto, siguiendo el esquema, sera tan siple como incluir en la entrada del supuesto mdilo de desencriptacin DES otra salida del mismo generador de IVs. El cifrado simtrico es seguro cuando se usa un algoritmo y sistema de cifrado correcto.

Cifrado Asimtrico El cifrado simtrico es seguro, es cierto pero estar siempre enfrentado a una serie de ataques que antes o despus es posible que sean rotos. Y su principal desventaja no es esa es la key. El cifrado asimtrico apareci como alternativa a ello. Pero vamos a ver primero la necesidad del cifrado asimtrico, sera absurdo crear un sistema que no tenga una utilidad. Hemos dicho que el cifrado simtrico tiene dos problemas. El primero de ellos es que est basado en algoritmos de dos sentidos, es decir, prcticamente (por no decir todas) todas las transformaciones que sufre el bloque por las diferentes etapas son funciones invertibles que a travs de la misma key se puede reconstruir el mensaje (dato) original. Esto implica que la fortaleza del algoritmo simtrico recaiga tan solo en las transformaciones algebraica que se realizan sobre el bloque. De ah que prcticamente todos los cifrados simtricos que se han estudiado antes o despus se descubren diferentes ataques a sus diferentes etapas. Por ejemplo, para AES existen ataques exitosos en versiones reducidas de este, es decir, AES con menos etapas. Si AES-128 posee 10 etapas, a lo mejor se ha logrado ataques que pueden considerarse una roptura (es decir, que son computacionalmente posibles) para versiones de 6 o 7 etapas tan solo. La idea de estos ataques es ir logrando cada vez ms romper cada etapa, de modo que al ir aadiendo una etapa ms, el coeste computacional pueda considerarse factible. Si se llega a obtener un ataque a AES-128 en el que el coste computacional obtenido sea de 280 (por ejemplo) se considerar una roptura, frente a 2128 posibilidades iniciales. El segundo problema al que se enfrenta el cifrado simtrico es la Key. La key es necesaria tanto para cifrar un mensaje como para desencriptarlo. Esto implica que tanto origen como destino tengan que compartir dicha Key. Esto a simple vista puede carecer de importancia, pero esto quiere decir que si queremos realmente una seguridad decente, en el mejor de los casos tendramos que tener una key diferente de comunicacin con cada uno de los usuarios con los que deseamos entablar una comunicacin segura, dado que no usaramos nunca la misma key con otros usuarios, de ser as otros usuarios podran leer los mensajes que eran destinados para otros. Esto provoca la necesidad de mltiples keys para cada usuario, lo cual es engorroso e inseguro, dado que la comodidad podra implicar usar la misma key en todas las comunicaciones y esto supondra un problema de seguridad.

El cifrado simtrico resuelve estas dos cuestiones. La primera de ella haciendo uso de lo que podramos llamar Matemtica Imposible. En el cifrado simtrico se logra un algoritmo de cifrado de un nico sentido, el cual no es computacionalmente viable el invertirlo. Podemos decir as que existen en realidad dos algoritmos diferentes dentro de un esquema de cifrado asimtrico, un algoritmo que encripta y otro que desencripta. Y al contrario que sucede con las transformaciones o la lgebra aplicada a un algoritmo

simtrico, en la criptografa asimtrica esta funcin suele ser mucho ms simple, lo cual no implica que sea ms rpida, todo lo contrario. As por ejemplo el cifrado AES requiere de 10 etapas mnimas para completar el cifrado de un bloque, mientras que el el cifrado RSA esto se limita a una simple funcin, aunque lo que no es simple es la teora y el clculo de dicha funcin. Estas funciones se basan en la premisa de que es imposible invertirlas, as por ejemplo tenemos el problema matemtico de la factorizacin (usado en RSA) y el del logaritmo discreto (usado en ElGamal). Vamos a basarnos por simplicidad y fcil compresin en RSA. Posiblemente hasta los nios ms pequeos aprenden a temprana edad que es la factorizacin de un nmero. Factorizar un nmero no es ms que encontrar sus factores, es decir, los diferentes nmeros que lo dividen, es decir, aquellos nmeros que al dividirlo dan como resto cero: Factorizacin de 20: 1,2,4,5,10 ya que 20 mod 10 = 0 20 mod 5 = 0. Todos sabemos factorizar un nmero, el problema radica en dicho mtodo. El problema reside en que la nica forma real de obtener los diferentes factores de un nmero (as como saber si dicho nnero es por ejemplo primo) radica en ir dividiendo dicho nmero por cada uno de los nmeros desde el 2 (el 1 es factor de todos los nmeros) hasta n-1, siendo n el nmero a factorizar. Si disponemos de un nmero relativamente pequeo como el 101, podemos simplemente ir dividiendo este por 2, por 3, por 4 hasta llegar al 99. En realidad a la hora de encontrar los factores no es necesario llegar a dicho nmero, tan solo es necesario realizar Raiz (n) operaciones. Es decir, en el caso que el nmero a factorizar fuese 101, en realidad tan solo sera necesario ir probando Raiz (n) = 10 aprox, es decir, despus de 10 operaciones podramos conocer si realmente 101 es primo: 101/2, 101/3, 101/4 101/10. Esto podra parecer no tener complicacin alguna, 10 operaciones podramos hacerlas incluso a mano. Pero que sucede cuando el nmero a factorizar es infinitamente mayor? Podramos pensar que un PC actual podra manejarlo en segundos, pero esto no es as. Existen diferentes algoritmos que intentan dar una opcin viable a la factorizacin sin necesidad de usar divisiones una a una, el problema es que estos algoritmos no son fiables al 100% ni mucho menos, produciendo lo que se conocen como falsos nmeros primos. Aun as, cuando se manejan los nmeros tan ingentes que pronto veremos, ni haciendo uso de estos algoritmos sera posible. Vemos por tanto en este caso, que la matemtica detrs de la factorizacin es ms que conocida, es sencilla, pero es computacionalmente imposible para grandes nmeros. Respecto al segundo problema comentado, la key, en el cifrado asimtrico no existe una sola key, sino dos. Una key se denomina como clave pblica y la otra como clave privada. El concepto es simple. Cada una de las claves son complementarias y pueden ser usadas tanto en el algoritmo de encriptado como en el de desencriptado, es decir, lo que encripta una clave lo desencripta la otra. No hay que pensar en clave pblica como clave para desencriptar, sino clave que se distribuye a todo aqul con el que deseamos entablar un canal seguro. A diferencia que el cifrado simtrico en el que es necesario una key nica para cada canal de comunicacin, aqu ser la clave pblica la que ser usada para todos. Este concepto choca al principio, una clave que se da a conocer a todos. Por otro lado la clave privada ser el mayor secreto para su dueo, y es aqu donde reside la vulnerabilidad desde mi punto de vista del cifrado asimtrico. Visto esto, es lgico asumir que el par de

claves (privada y pblica) deben de estar relacionadas de modo alguno, pero sin que pueda suponer un riesto el conocimiento de dicha clave pblica. Estas dos caractersticas hacen que el cifrado asimtrico sea a da de hoy posiblemente el sistema ms seguro en cuanto a encriptacin de datos, y ello puede verse diariamente. Todas las comunicaciones cifradas a da de hoy que requieren de una privacidad importante, estn basadas de un modo u otro en cifrado de clave pblica (o cifrado asimtrico). No obstante no todo son ventajas. El cifrado asimtrico para empezar requiere de una capacidad de computacin muy superior a la del cifrado simtrico para realizar la encriptacin o desencriptacin, llegando a ser cientos de veces ms lento. Por otro lado se requieren por regla general keys de una longitud muy superior a lo que es habitual encontrar en el cifrado simtrico. Por ejemplo AES-256 (Key de 256 bits) frente a RSA, que puede usar Keys de entre 1024-4096 bits. Aunque una Key de 4096 bits (512 Bytes) sea un tamao irrisorio para las comunicaciones, nadie sera capaz de recordar jams una clave de 512 caracteres. En contrapartida, con AES-256 (32 Bytes) por un lado no sera complicado recordar una frase de 32 caracteres, pero adems no es necesario, dado que generalmente las subkeys usadas son generadas apartir de nuestra clave introducida. Pero en el cifrado asimtrico esto no funciona as, no existen keys derivadas, una para encriptar todo el mensaje, una para desencriptar todo el mensaje. Este problema de keys grandes se une al echo de la necesidad de que una Key pblica sea conocida. Si deseamos que alguien encripte un mensaje hacia nosotros, este mensaje deber de cifrarlo usando nusetra key pblica, luego dicho usuario deber tener acceso a nuestra key pblica. Del mismo modo si queremos responder a dicho mensaje, tendremos que o usar la clave publica de dicho usuario para encriptar la contestacin o encriptar la contestacin con nuestra clave privada, ya que el receptor dispondr de nuestra clave pblica para desencriptarlo o su clave privada. Para que esto pueda ser posible, hace ya mucho tiempo que se establecieron bases de datos de claves pblicas, de modo que cualquier persona pued acceder a ellos de forma simple y conocer la clave pblica de cualquier persona.

Posiblemente los dos algoritmos de cifrado asimtrico ms conocidos sean como hemos dicho RSA y ElGamal. Cada uno de ellos se basa en una imposibilidad matemtica y por comodidad vamos a explicar como funciona RSA a grandes rasgos. RSA como hemos dicho se basa en la imposibilidad matemtica de factorizar un nmero grande. El proceso no es muy complejo. Lo primero es generar las claves que sern usadas, tanto la privada como la pblica:
1. Tomar dos nmeros primos, llamados p y q, los cuales por seguridad se requiere que ambos tengan una longitud de bits similar, para garantizar en caso de un posible ataque el peor de los casos posibles, y por otro lado que puedan escaparse a los algoritmos conocidos de bsqueda de primos. Estos dos nmeros es normal encontrarlos de al menos 512 bits de longitud, es decir, un nmero con ms de 154 cifras.

2. Se calcula n = p x q, y acto segido la funcin Phi de Eulerm definida como Phi (p x q) = (p1)(q-1). La funcin Phi de Euler calcula el nmero de coprimos que existen a un nmero dado. dos nmeros son coprimos si no tienen ningn factor en comn salvo el 1. Es decir, aunque el 10 no es un nmero primo, el 14 es coprimo de 15, dado que tan solo comparten el factor comn uno. Dado que tanto p como q son nmeros primos (ta solo divisibles por 1 y por ellos mismos) poseern cada uno un nmero p-1 y q-1 de coprimos cada uno. 3. Se escoge un nmero e que se encuentre entre en el intervalo 1 < e < Phi(p x q), de modo que e y Phi sean coprimos entre ellos. Si e a su vez es primo mejor. 4. Se calcula d en la siguiente funcin: d x e = 1 (MOD Phi (pxq)). de = 1 MOD Phi(pq) es quizs el principal problema de comprensin en RSA. Esta funcin recibe el nombre de multiplicacin modular inversa, y se calcula de forma simple gracias al mtodo extendido de Euclides. En realidad es tan solo matemticas aplicadas. NOTA: Los Iguales que son especificados en estas igualdades en las que implican operaciones modulares, no son en realidad Iguales, sino Congruentes, es decir equivalentes. Escribir d x e = 1 (MOD Phi (pxq)) siendo ese Igual el smblo de congruencia, significa que 1 = dxe MOD Phi, siendo ese Igual un Igual de los de toda la vida.

Despus de estos 4 pasos, la clave privada y la clave pblica estarn ya creadas. La clave privada corresponder entonces a la tupla Clave_privada (n, d), mientras que la clave pblica a la tupla Clave_pblica (n, e). Una vez obtenidas sendas claves tan solo es necesario aplicar la funcin de encriptacin o desencriptacin. Por cuestiones de Padding y seguridad, el mensaje es convertido a un nmero entero m, menor a n: me = Cifrado MOD n -> Se obtiene as un valor en Cifrado Cifradod = m MOD n -> El valor Cifrado ser desencriptado por medio de dicha funcin y se obtendr m, es decir el mensaje original. Tan solo es necesario deshacer el padding. Como se pueden ver, en realidad las funciones de encriptado y desencriptado son sencillas. Si quisisemos llevar esto a un ejemplo real a pequea escala (con nmeros pequeos): a) p = 101, q = 103 -> Ambos nmeros son primos, de longitud similar (aunque nmeros muy pequeos). b) n = p x q = 101 x 103 => n = 10403. Phy (10403) = (101 1) (103 1) => Phi = 10200 c) 1 < e < Phi => 1 < e < 10200 => e = 13. 13 a su vez es primo y coprimo de 10200. Esto puede comprobarse de forma sencilla gracias al algoritmo de Euclides. d) d x e = 1 (MOD Phi (p x q)) => d x 13 = 1 MOD 10200. Esta ecuacin se expresa del mismo modo como: d-1 = e MOD Phi. Si se aplica el mtodo extendido de Euclides se puede obtener de forma sencilla la identidad de Bezout. El mtodo de euclides no es ms en realidad que ir dividiendo dividendo entre divisor. Una vez se realiza la operacin, el divisor pasa a ser dividendo y el resto divisor y se realiza otra iteracin, hasta que se obtiene un resto de 1. A cada iteracin se le calcula sus dos coeficientes para generar as la igualdad de Bezout. En nuestro caso para la iteracin 5 (en la cual el resto es 1) del mtodo

extendido de euclides estos son 5 y -3923. calcular estos coeficientes se obtienen por sustitucin de las iteraciones anteriores. En la iteracin 3 se obtienen los coeficientes sustituyendo en esta la igualdad de bezout obtenida en la iteracin una y dos. Las iteraciones una y dos a su vez se conocen de antemano: restoi= Combi = Comb (i-2) + Comb (i-1)
Ronda Divndo. Div. Cociente Resto 1 2 10200 13 10200 13 10200 13 Sustitucin Combinacin 10200=10200*1+13*0 13=10200*0+13*1 Coef. Coef. 1 2 1 0 0 1

10200 13 784

8=(10200*1+13*0)8=10200(10200*0+13*1)* 13*784 784 5=(10200*0+13*1)5=13-8*1 (10200*1+13* 784)*1 3=(10200*1+13* 784)-(10200*1+13*785)*1

8=10200*1+13* -784

-784

13

5=10200*-1+13* 785

-1

785

3=8-5*1

3=10200*2+13* -1569

-1565

2=5-3*1

2=(10200*-1+13* 785)-(10200*2+13* - 2=10200*-3+13*2354 1569)*1 1=(10200*2+13* 1569)-(10200*3+13*2354)*1 0=(10200*3+13*2354)(10200*5+13* 3923)*2

-3

2354

1=3-2*1

1=10200*5+13* -3923

-3923

0=2-1*2

0=10200*13+13*10200

-13

10200

Pese a la aparente complejidad, si se presta atencin al procedimiento realizado rpidamente se comprende como se ha realizado. Una vez obtenido los dos coeficientes, tan

solo nos quedara que d = Phi + Coef. 2 (Resto 1) => d= 10200 3923 = > d = 6277. Si deseamos verificar esto: d x e = 1 MOD (Phi(pxq)) => 6277 * 13 = 1 MOD 10200 => 81601 MOD 10200 = 1. Es decir, se cumple. e) Con esto tendramos la claves privadas y pblicas calculadas: Clave Privada (n->10403, d->6277), Clave Pblica (n->10403,e->13) Cabe destacar que todo este proceso de 4 fases es tan solo llevado acabo una sola vez, y estas claves sern las que sean usadas durante meses o aos sin ningn tipo de problemas. Una vez se tienen estas dos claves, el resto tan solo es aplicar la funcin de encriptacin o la funcin de desencriptacin. Continuando con el ejemplo imaginemos que quisisemos encriptar la palabra Casas, y que estamos usando un sistema simple de translacin de dichos valores a ASCII en hexadecimal. Imaginar tambin que se tiene un Padding que inserta en el mensaje un valor de 001 cada dos caracteres: Mensaje Original: C -> 043 a -> 061 s -> 073 a -> 061 s -> 073 Mensaje Con Padding: 43 61 01 73 61 01 73. Es decir, cada dos bytes se incrusta un 01. Tamao de la palabra: 2 Bytes. Es decir, se especifica la cantidad de Bytes que se van a tomar para realizar la codificacin, en este caso por ejemplo 2. Es decir, se divide el mensaje con el padding incorporado en grupos de 2 bytes, si el nmero es impar (como en nuestro caso) se aade un byte ms de padding al final para rellenar Codificacin 1- >4361, Codificacin 2 -> 0173 Codificacin 3 -> 6101 Codificacin 4 -> 7300 me = Cifrado MOD n ->Se cifrar usando la clave pblica. En caso de que se quisiese cifrar con la clave privada, en vez de e se usara d. 436113 = Cifrado MOD 10403 => Cifrado = 436113 MOD 10403 = 7905 017313 = Cifrado MOD 10403 => Cifrado = 017313 MOD 10403 = 6398 610113 = Cifrado MOD 10403 => Cifrado = 610113 MOD 10403 = 3597 730013 = Cifrado MOD 10403 => Cifrado = 730013 MOD 10403 = 3217 En mensaje cifrado por tanto correspondera a la cadena hexadecimal: 79 05 63 98 35 97 32 17, algunos de esos valores tendran representacin en ASCII y otros no. El proceso de desencriptacin sera similar: Cifradod = m MOD n 79056277 = m MOD 10403 => m = 79056277 MOD 63986277 = m MOD 10403 => m = 63986277 MOD 35976277 = m MOD 10403 => m = 35976277 MOD 32176277 = m MOD 10403 => m = 32176277 MOD 10403 = 7300 10403 10403 10403 = = = 4361 0173 6101

Para poder calcular el mdulo a tales cifras exponenciales no servir una calculadora normal, es necesario recurrir a tcnicas concretas para el clculo de mdulos a exponenciales. Un buen punto de partida para poder realizar esto sera: AQUI Como se puede observar, los resultados obtenidos son exactamente los mismos que los iniciales, la cadena desencriptada correspondera a 43 61 01 73 61 01 73 00, eliminando el Padding nos quedara 43 61 73 61 73 que se traducira en ASCII de nuevo como Casa. Segn el esquema propuesto se puede ver la necesidad del Padding. El Padding en RSA toma una importancia aun mayor, dado que no solo sirve para aadir al final bytes que puedan faltar para rellenar, sino que es importante incluir ciertos bits o bytes (de forma reversible) en el mensaje original, de este modo RSA se hace resistente a ataques conocidos como textos especficos, aunque las vulnerabilidades sern tratados en el ltimo capitulo de este artculo. El Padding debe de ser conocido por todos, no debe de ser un secreto. Como se puede comprobar, RSA (o los algoritmos de clave pblica en general) no son en realidad complejos por sus funciones, sino por la carga matemtica que hay detrs de ellos. Las funciones en RSA para cifrar son muy simples, 4 variables de las cuales se conocen siempre 3 y dos operaciones, una exponencial y otra modular. La seguridad en cambio radica en que es virtualmente imposible obtener a partir de la clave pblica la clave privada. Como hemos visto, la clave privada corresponde a la tupla n y d. Mientras que n es tambin un valor dado por la clave pblica, d es calculado desde la clave privada a la hora de generar las claves. El clculo de d se podra intentar, pero como hemos visto anteriormente, d depende de Phi (p x q) y para calcular Phi (p x q) es necesario conocer p y q. Aqu es donde radica el problema de la factorizacin. Sabemos que n = p x q y es un dato conocido, pero no conocemos el valor de p y el valor de q necesario para poder calcular Phi y posteriormente d. Para poder obtener p y q sera necesaria la factorizacin de n, y esto como hemos dicho no es viable. Es computacionalmente sencillo obtener dos primos con un nmero de bits muy grande. Es computacionalmente sencillo multiplicar dichos primos entre ellos. Y es computacionalmente imposible revertir el proceso y obtener los factores de dicho producto, es un camino solo de ida, si perdisemos q y p sera imposible volver a encontrarlos. Para aquellos que les pueda interesar RSA, recuerdo bien el programa DisMat, una herramienta para aprendizaje sobre RSA y otras cuestiones igualmente interesantes.

RSA no es el nico sistema de clave asimtrica que existe. En la otra cara de la moneda tenemos ElGamal, que est basado en algunas asunciones similares pero en principios diferentes. No voy a detallar el funcionamiento de ElGamal por dos razones. La primera porque honestamente se escapa a los conocimientos matemticos del redactor (es decir, a mi) y no sera tico buscar informacin sobre ello y plasmarla aqu sin comprenderla. Y por otro lado, aunque ElGamal es un sistema libre (RSA est patentado), su popularidad es relativa, siendo RSA inmensamente ms usado y popular. De todos modos ElGamal si podemos decir que aplica otro principio de la matemtica imposible, llamado como

logaritmo discreto. Lo gracioso es que esto lo hemos visto a menos de pasada dentro de RSA. El problema reside en esta ecuacin: a = bx MOD n => x = log discretob (a) Siendo a, b y n nmeros conocidos y X la incgnita. El problema es poder calcular X. En RSA nos tenemos que enfrentar a esta ecuacin, pero en nuestro caso no tenemos que calcular X, tan solo a. En ElGamal, poder obtener la clave privada implicara resolver dicha ecuacin, y esta es imposible de resolver computacionalmente, es decir en un tiempo razonable, de nada sirve que pueda ser resuelto con un ordenador funcionando durante miles de aos.

Los algoritmos de cifrado asimtrico como RSA son extremadamente seguros. El echo de que sea lentos comparados a los sistemas de cifrado simtrico hace que normalmente se opte por sistemas hbridos de los que sern tratados en los prximos captulos. Dado que el potencial de computacin es limitado estos sistemas suelen estar a salvo de cualquier posible ataque contra el propio sistema (no implica que no sean vulnerables a otros ataques), pero todos sabemos que la capacidad de clculo de los dispositivos actuales se incrementa exponencialmente cada ao que pasa. Esto significa que cada da que pasa se est un poco ms cerca de alcanzar el reto computacional que plantean tanto los cifrados simtricos como AES-256 a cifrados asimtricos como RSA-1024. La ventaja de estos segundos, es que estn diseado para trabajar con longitudes muy superiores, mientras que no sucede lo mismo con los cifrados simtricos. Es probable que dentro de X aos, AES128 sea considerado inseguro, o incluso su sistema sea roto, como en su da lo fue RC4. En cambio encontrar una roptura en sistemas como RSA es harto ms complicado.

Certificados y Firmas Digitales

El cifrado de datos es un mecanismo que garantiza que nuestros datos, aun cuando puedan ser interceptados por otros, permanecern seguros. Por otro lado, los Hash nos dan un mecanismo para poder garantizar la integridad de un mensaje. Fue hace ya tiempo cuando se pens en una aplicacin prctica sencilla de estas dos tecnologas, y comenz a hablar de Certificados digitales. Pronto fue igualmente necesario el concepto de firma digital, un sistema de autentificar algo. Una tecnologa se crea fundamentalmente pensando en algo. As, el fundamento del cifrado de datos es simple, que cuando un mensaje sea interceptado no pueda ser ledo o comprendido por una tercera persona a la cual no est destinado. Pero esto no impide que el mensaje pueda ser modificado, deteriorado, falseado Imaginar una carta postal que se escribe con tinta invisible. Alguien que la intercepte quizs no pueda leer el contenido real de esta, pero puede coger otra carta, rellenarla con la informacin que desee y enviarla de nuevo al destino de esta. La pregunta es Como podr el destino saber si dicha carta ha sido modificada? En el caso de la carta quizs con un sello, una firma aqu el concepto

ser el mismo, y podramos decir que el fundamento de un Hash criptogrfico es precisamente la integridad. A raz de la necesidad tanto de proteger el contenido de los datos en las comunicaciones, como de autentificar el emisor y el destino, como garantizar la integridad del mensaje, se cre el concepto de Infraestructura de Clave Pblica (PKI). Este concepto no es ms que la aplicacin prctica en las comunicaciones de los conceptos que hemos visto anteriormente (y alguno ms que veremos en este captulo): Hash, Cifrado Simtrico y Cifrado Asimtrico. En este captulo vamos a intentar comprender bsicamente cada uno de los elementos que constituye una infraestructura de clave pblica (PKI), y veremos como cada siguiente elemento se hace necesario para el correcto funcionamiento de todo el sistema:

Infraestructura bsica Certificado: Necesidad de asociacin usuario/empresa Claves Firma: Necesidad de autentificacin de todas las partes e integridad

Infraestructura bsica Vamos a intentar aplicar todos los conceptos explicados a un entorno real que deseamos que sea completamente seguro. Para hacer esto tenemos que tener una serie de consideraciones, tendremos que crear una infraestructura en la cual podamos aplicar y hacer viable nuestras necesidades. Hemos dicho que el objetivo ser triple a la hora de desear crear un canal de comunicacin seguro entre dos partes: El cifrado, la autentificacin y la integridad. Empezemos por lo tanto por la primera de las partes, el cifrado. Lo primero que deseamos es que nuestros datos sean interceptados o no por una tercera persona, esta no pueda acceder a ellos. Hemos dicho que para ello disponemos de dos sistemas muy buenos, el cifrado simtrico y el cifrado asimtrico. Cada uno de ellos tiene ventajas e inconvenientes. Cual es ms factible de usar? En principio vamos a pensar que el cifrado asimtrico por una razn muy simple: Adems de ser ms seguro tan solo requiere de un par de claves (publica y privada) para el nmero que sea de canales de comunicacin a entablar. Realizar esto por medio de un cifrado simtrico sera muy costodo en cuanto a infraestructura, dado que Como crearas una base de datos en la cual se pudiese almacenar cada usuario un nmero sin fin de keys asociada cada una de ellas a un usuario o entidad diferente? Sera impensable. En cambio mediante el cifrado por clave pblica esto podra simplificarse, dado que tan solo es necesario hacer pblica una sola key para todos los canales de comunicacin posibles, no una para cada canal. En realidad el sistema actual usado es hbrido, pero esto se ver ms adelante, para nosotros simplemente decir que se opta de momento por el cifrado asimtrico, en nuestro caso RSA. Una vez definida la necesidad de un sistema de clave pblica y las ventajas que esta nos aporta, aparece el primer problema: Distribucin. Hemos explicado que el sistema de cifrado asimtrico es muy eficiente e increblemente verstil, lo que encripta una key

privada lo desencripta la pblica, lo que encripta la pblica lo desencripta la privada. De ah la necesidad de que la clave pblica sea exactamente eso: Pblica. Pero como podemos hacer que cualquier usuario del planeta pueda tener acceso a dicha Key? Aqu es donde comienza a crearse la verdadera PKI, de la necesidad de ir solventando los por menores del camino. La nica forma de que cualquier usuario conozca nuestra key pblica es disponer de bases de datos en las que se encuentren almacenadas las claves pblicas de todos los usuarios. A esto se le conoce como repositorios de claves pblicas. Ahora, cualquier usuario puede enviar su clave pblica asociada a un correo electrnico, nombre, apellidos Pero de forma pareja aparece la necesidad de algn control sobre dichas bases de datos. Que sucede si una key ha sido comprometida o ya no es vlida? Es necesario por tanto otro Repositorio , en este caso un Repositorio de Revocacin de claves pblicas. Con estos dos sistemas podramos garantizar el funcionamiento correcto del cifrado de datos entre dos usuarios. Estos repositorios existen a da de hoy, la mayora de ellos se encuentran sincronizados con los otros para que todos tengan los mismos datos. Por ejemplo podemos visitar uno de ellos: Repositorio de Claves Publicas del MIT En dicho repositorio podemos buscar cualquier cadena de texto, ya sea nombre, apellidos, correo electrnico o ID de la clave:

Type bits/keyID

Date

User ID

pub

4096R/B9A35B9C 2009-12-02 Carmen Mendes <cmendes@transnumeric.com>

pub 2048R/F4D68EB5 2009-11-07 Mara del Carmen Rodrguez Sardia <mariadelcarmen@gens-osorio.es>

pub 1024D/9BC23DEF 2009-10-15 carmenalves (ola) <carmen.alves.05@formando.gti.pt> ...

Por supuesto si continuamos el link de la KeyID nos topamos directamente con la clave pblica de Carmen:
-----BEGIN PGP PUBLIC KEY BLOCK----Version: SKS 1.1.0 mQENBEuGtJwBCAD0EM6+cVCIrc2t5CLWhrdwPrTbb4ZbTAKuLjAjULl3K+/usQg7JT0Y+qL6 Z/eGB8krZgzzT77bQHKVAw7NeUZGSMDl+kSIT9k5gx/vWxdyuBUeJODkd7IldiGbW5yhGz92 0LGbQ5weF2GT8DewCtawOsO46baygPIgiVR99vArzNyiX+KFnrUaniVbjbiN8KQY9Nvmdvyz BU77W5SDRc4LbuOv5GCtnPKjlVQE5JApoelpZi2fiJkH/kKcf4ZTc0nSK8e8duHYB+zrKrxO ICKHWXWgLBV9aZkoCH35oShK3JpSeimnV3yqwqz2zt32p/JNKO02krPNNIUL+AqVivEfABEB AAG0SmNhcm1lbiByZXF1ZWpvICh1biBhbWlnbyBtaW8gc2UgbXVyacOzIGNvbmdlbGFkbykg PGZvMjAxMGNhcm1lbkBnbWFpbC5jb20+iQE+BBMBAgAoBQJLhrScAhsjBQkJZgGABgsJCAcD

AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBeKv2mzKxFxS0wCACcC6fWZ9IliyKHI8gZBEl3s9Sd WWlUJo/PNgbzEoq3N/aiy47+ITo/Qax9+PXYUUOH6Zx+CLb4NMyplSo3cESDlg4O/hzkypP6 9Yj6JflHQcqmWfGsWwqf3kiGSWopd8osKdb5bpvKfXI+JKc8Gj5l64JUa0f6BIPIL3/9/Uci EhnEyHG0b2gJx/f3bybAG+mpBo3VnV/alTfZbX8qnen3Rqg1TPxEyfJjR6E4QrSkeHb8MJp9 ZGO58IWvWAPADJJoK2alKJMRKjeZKFjqcolr4mgNhRhg3iD77SmL1hskwfCinPXGnmimV/Xl VH0qTX/4Jem6aTG+9aD8u8r3p4LyuQENBEuGtJwBCADALhMeR4PFXzKcxDUzn5yWbckFrz97 ONCbL1C0G/4Wg8fV3t0Vchzg6aKsEYUZSfTe5Ph0rqLWs1cfjgMxrCRYTfzmCffIWBmXixu7 iDuj6bRshY+9F03xFA0X/GJG1bZ/3JuIYTP804UU1/OsH+cFsyj1CnoUNz1zZ5rvm/76VqL1 vBskTyD7cfEPrSTh5HfBu8EatdI0rCPezyzZeE0IhWYg7OChBK6FzkaIEZifpxI7/KSadPNw NLO0WdLmFhqLqS/Pwt4oCcMxljB9zoO/KGRyvw4nY6BilItFwaIfOjDbrVqDSnG9RZ8+Cevo TfPi1j1VsBpc113vMqs0g14hABEBAAGJASUEGAECAA8FAkuGtJwCGwwFCQlmAYAACgkQXir9 psysRcVvjgf9F0o3Q3/MbLMriwe9naCXuy2xcceWyZ9vp6ZPm5zoD1Tt7aWRBeFUhk/T88sa SqcpVqZSNtsdjJl7oHXVcFKeccIebOs826GIMzWgT6kCl2r79RY4W7b0iaPzljH7ayX7Ce3Z UM7Z0JhCmjH6aszc/dXd3JkHR9cxiY9A1HWrgGzd2RlNCYOVB1kokteVE9+CXCyJwAelSCLR GAYl33oyxGDKxngVCdeBRxgCeTU0szL7NXMNi3Y2cQCHCiEwTspKXS+wOtos66vgYLYXdgJs KvW0gau6bUwBouD7aXZOkubfpZ3J85X6KcLuPAQfJlhtuufimJ3y7/+B09c0TD+Osw== =PqHr -----END PGP PUBLIC KEY BLOCK-----

Ana desea enviar un mensaje cifrado a Carmen: a) Ana accede a un Repositorio de Claves pblica para obtener la Clave pblica de Carmen, para ello busca en la base de datos por Carmen. Es posible que haya ms de una (puesto que alguna puede estar revocada) b) Ana con la clave en su poder verifica que esta key no se encuentre en la lista de Revocacin. Dado que no est, considera que la key est en uso y es vlida. c) Ana encripta el mensaje con la clave pblica de Carmen y le enva el mensaje d) Carmen desencripta el mensaje con su clave privada. De este modo Ana puede enviar un mensaje cifrado a cualquier usuario del mundo que est usando un sistema de clave publica, sin necesidad siquiera que el emisor use dicho sistema, y con la garanta de que dicho mensaje tan solo podr ser desencriptado por el poseedor de la key privada pareja a la key pblica del repositorio. Este sistema logra el objetivo del cifrado de datos. Pero que sucede ahora con la autenficicacin? En el ejemplo expuesto, Ana no puede asegurar de ninguna forma que la clave pblica obtenida del repositorio accedido proceda de Carmen. S, es posible incluso que en dicho repositorio quedase indicado nombre, apellidos, direccin, DNI pero dado que son repositorios a los que todos tienen acceso, cualquiera podra introducir datos falsos en ellos. Por ejemplo, podra crear una key publica/privada a nombre de otra persona, de esta forma cuando alguien quisiese enviarle a dicha persona un mensaje, lo encriptara con mi pblica. Aqu es donde nace la necesidad de autentificacin, de algn sistema por el cual Ana pueda estar convencida que la clave pblica obtenida pertenezca a Carmen. Para esto se opta por dos sistemas diferentes, aunque ambos se basan en la misma premisa: Cadena de confianza. Imaginar que de algn modo se pudiese dar un punto positivo a una clave pblica, de forma que cuantos ms puntos positivos tenga una Key pblica de un repositorio indicase a terceras personas que dicha key es vlida. As por ejemplo yo podra dar un punto positivo a la clave pplica de mis hermanos, puesto se fehacientemente cual es la que pertenece a

cada uno de ellos. De este modo, si una tercera persona desease enviarme un mensaje cifrado a m, se fiara en caso de duda ms de aquella clave pblica que tenga ms puntos positivos de personas diferentes. Ahora imaginemos que Ana desea enviar un mensaje cifrado al mismsimo Linus Torvalds (El cual espero no le importe que use su nombre para estos ejemplos) para consultarle un bug crtico en el kernel de linux. Lo primero que hara sera acceder al repositorio y buscar por Linus Torvalds, dado que ni siquiera conoce su correo electrnico. El repositorio le devolvera lo siguiente:
Type bits/keyID Date User ID

pub

1024D/825D2E82 2008-09-03 Linus Torvalds (Teste) <linus@linux.org>

pub

1024D/D080B7A0 2008-07-26 *** KEY REVOKED *** [not verified] Big Gay Al (kay) <letsseesomelove@love.com> REVOKED KEY (u suck) <FUNBO@T> Linus Torvalds (revoke revoke revoke) <werfsdfasdf@fakefakefake.com>

pub

1024D/006D1B6D 2005-11-11 *** KEY REVOKED *** [not verified] Danilo G. Magrini <danilo.magrini@gmail.com> Danilo G. Magrini <danilomagrini@uol.com.br> Danilo G. Magrini <danilo@onclicksistemas.com.br> Danilo Gustavo Magrini (Linus Torvalds) <danilomagrini@uol.com.br>

pub 1024D/8BC6EDEF 2005-11-10 Danilo Gustavo Magrini (Linus Torvalds) <magrini_sp@superig.com.br>

pub 1024D/76E21CBB 2005-04-23 Linus Torvalds (tag signing key) <torvalds@osdl.org>

pub

1024D/CE904A82 1999-11-21 Linus Torvalds <vnixroot@netscape.com>

pub

1024D/449FA3AB 1999-10-05 Linus Torvalds <torvalds@transmeta.com>

pub 1024R/A86B35C5 1996-06-08 Linus Torvalds <Linus.Torvalds@Helsinki.FI>

Ana es una chica lista, pero segn el repositorio existen 8 posibles claves pblicas supuestamente todas correspondientes al bueno de Linus. Sin dificultad Ana descartara de forma automtica las que estn marcadas como Revocadas, lo que deja el listado con 6. La primera se podra descartar dado que aunque el correo podra ser legtimo, pone (Test) podemos imaginar que fue creados con fines de testeo, adems, la fecha de la clave es relativamente nueva. La cuarta la excluimos porque el nombre ni siquiera pertenece al de Linus. De este modo tan solo nos quedaran como posibles las 4 ltimas. la quinta no obstante puede leerse como (tag signing key) que podramos suponer que se trata de una clave tan solo para firmas (esto se vers ms adelante), as que de momento la descartamos tambin. Las otras tres restantes podra parecer legtimas a simple vista. Como Ana quiere asegurarse, quiere ver lo que hemos llamado como votos positivos de ellas. Si accedemos a la sexta obtenemos la siguiente informacin:
pub 1024D/CE904A82 1999-11-21

uid Linus Torvalds <vnixroot@netscape.com> sig sig CE904A82 1999-11-21 __________ __________ [selfsig] sig sig 8061A830 2005-05-30 __________ __________ Dan Mundy <harob02@earthlink.net> sub 2048g/1EEE5A92 1999-11-21 sig sbind CE904A82 1999-11-21 __________ __________ []

Los votos positivos que hemos nombrado en realidad son firmas, dado que aun no hemos hablado de ellas tan solo imaginamos que son algo as como voto de confiabilidad. En este caso vemos que tan solo posee una firma creada por l mismo selfsig y otra firma (voto) creado por un tal Dan Mundy. Ana, que no es tonta, imagina que una persona como Linus, de tener una clave pblica en estos repositorios tendr seguro bastantes votos de confiabilidad. Luego la rechaza. Esto deja a Ana con dos opciones, las dos ltimas. Ana conoce un poco la vida de Linus y le suena que trabaj o tubo relacin con trasmeta.com, luego parece un buen punto de partida. No obstante sabe tambin que Linus es finlands, nacido en Helsinki, lo que quiere decir que las dos claves que aparecen podran ser completamente legtimas. Y en este caso las dos pertenecen a l. No obstante, si nos adentramos en la ltima de ellas, generada nada ms y nada menos que en 1996!!, esto es lo que obtenemos:
pub 1024R/A86B35C5 1996-06-08 __________ [selfsig] H. Peter Anvin george a. r. hill Alexander Smith Kenyon Ralph H. Peter Anvin

uid Linus Torvalds <Linus.Torvalds@Helsinki.FI> sig sig A86B35C5 1996-06-08 __________ __________ sig sig 2A960705 1997-04-24 __________ __________ <hpa@zytor.com> sig sig 29BC0185 1998-01-24 __________ __________ <9x> sig sig 0C00E6AD 1998-08-21 __________ __________ <Sabin84@usa.net> sig sig CCBEA8D2 1998-09-02 __________ __________ <kenyon@san.rr.com> sig sig ACF5A545 1998-12-17 __________ __________ <hpa@zytor.com>

sig sig A4679654 1999-01-30 __________ <drizuid@drizuid.net> sig sig F0C36E09 1999-01-30 __________ druid@geocities.com> sig sig 29B0C351 1999-06-18 __________ <j.suelwald@gmx.de> sig sig FEEFE90B 1999-09-15 __________ sig revok FEEFE90B 1999-09-15 __________ sig sig 6470AB26 2000-03-02 __________ <cblancher@cmc.fr> sig sig A4C70528 2000-03-15 __________ <sentinel@freshshell.de> sig sig A24D8B4E 2000-08-10 __________ <cblancher@startem.net> sig sig 24901EE8 2001-05-31 __________ <simon@nullifynetwork.com> sig sig 9CD30D3D 2001-10-09 __________ <zcwong@hotmail.com> sig sig 01B45CE2 2001-10-09 __________ <zcwong@hotmail.com> sig sig D925418D 2004-04-18 __________ (Guitarman) <guitarman@ntdf.com> sig sig 6422D07C 2004-05-23 __________ (Root CA) <fabian_foerster@web.de> sig sig 0C877B34 2004-05-23 __________ (Root CA) <root-networks@web.de> sig sig FA81F1E6 2004-06-14 __________ <lrmm@comcast.net> sig sig AAE6022E 2004-12-28 __________ (RBOS) <karlheinz.geyer@lhsystems.com> sig sig 4D34B354 2004-12-28 __________ (DKB) <karlheinz.geyer@lhsystems.com> sig sig 8061A830 2005-05-30 __________ <harob02@earthlink.net> sig sig3 099A79AC 2005-07-12 __________ Vinakovsky <kvinakovsky@earthcam.com> sig revok AAE6022E 2005-07-28 __________ (RBOS) <karlheinz.geyer@lhsystems.com> sig revok 4D34B354 2005-07-28 __________ (DKB) <karlheinz.geyer@lhsystems.com> sig sig 6BEEAF8D 2008-08-02 __________ <heavyhenning@gmail.com>

__________ Drizuid __________ Drizuid <dark__________ Jens Slwald __________ [] __________ [] __________ Cedric Blancher __________ Alexander Smith __________ Cdric Blancher __________ Simon A Soanes __________ ZC Wong __________ ZC Wong __________ Kevin W. Peters __________ Fabian Foerster __________ The Root Networks __________ Thomas Shea __________ Karlheinz Geyer __________ Karlheinz Geyer __________ Dan Mundy __________ Konstantin __________ Karlheinz Geyer __________ Karlheinz Geyer __________ Kristoffer Warming

Ana comprende que efectivamente no solo ese puede ser un correo vlido de Linus, sino que tambin lo es su clave pblica. Puede comprobar que tiene una serie de firmas en su clave que de un modo reafirman que dicha clave pertenece a l. Se puede observar que 3 de las firmas (votos) estn igualmente revocados, pero aun as parece claro que esta es una clave vlida y legtima. La ltima forma pertenece a 2008, lo que nos puede hacer pensar que la cuenta est aun en activo.
pub 1024D/76E21CBB 2005-04-23 Linus Torvalds (tag signing key) <torvalds@osdl.org>

Pertenece tambin a l, es un correo que es ms que conocido por programadores y otros que frecuentan listas de correos del kernel de linux, lo que sucede es que aparentemente por ese nombre podemos deducir que Linus la usa tan solo para firmar, y no para encriptar (esto se ver como he dicho ms adelante) Llegados a este punto, Ana ha logrado dos objetivos. El primero cifrar los datos y el segundo asegurarse que dichos datos estn cifrados efectivamente y tan solo para Linus Tolvards, gracias al anillo de confianza que generan estos votos (que no son sino firmas digitales). Pero aun le queda a Ana un problema. La integridad. Como puede estar Ana convencida que el mensaje que reciba Linus no haya sido modificado por un tercero. Ana desea que en el peor de los casos y que este haya sido modificado, Linus pueda conocer que este ha sido modificado, as pueda contactar de nuevo con Ana y solicitarle de nuevo el envo del mensaje legtimo. Despus de un rato de meditacin, Ana recuerda la funcionalidad del Hash criptogrfico. Ana no podr garantizar nunca que el mensaje llegue sin modificacin alguna, pero puede garantizar que de ser modificado Linus se percatar de ello. Como? Ana recuerda que si aplica por ejemplo un Hash SHA-1 al mensaje cifrado y envia tanto el hash como el mensaje cifrado, Linus podra verificar si el hash especificado por Ana y si coincide con el Hash real del mensaje. Una tercera persona sino, podra interceptar el mensaje, crear un mensaje nuevo, cifrarlo con la key Pblica de Linus y envirselo en nombre de Ana. No obstante, segn este esquema una tercera persona podra igualmente interceptarlo, y como conoce el Hash que ha usado Ana, tan solo tendra que redactar el mensaje, encriptarlo, calcularle el nuevo Hash y enviar los datos a Linus. Es aqu donde aparece la necesidad de la firma digital. Ana ha comprendido las tcnicas de los hackers que quieren modificar su mensaje cifrado (sin saber siquira que hay dentro de dicho mensaje) as que ha descubierto la solucin definitiva. Ana, que tambin tiene usa sistemas de clave pblica tiene su propia clave pblica y privada: a) Ana redacta el mensaje y lo encripta usando la clave pblica de Linus b) Ana calcula un Hash SHA-1 al mensaje encriptado y este mismo hash lo encripta con su clave privada (A esto se le llama firma digital) c) Ana enva tanto el mensaje cifrado como la firma a Linus. d) Linus accede al repositorio de claves pblicas y busca la correspondiente a Ana y a dicha direccin de correo (del mismo modo que hizo Ana). Encuentra la que busca con muchos votos a su favor, y con la clave pblica de Ana es capaz de desencriptar el hash de Ana. Linus calcula el Hash SHA-1 al mensaje cifrado y verifica que ambos valores coinciden!! Luego el mensaje ha conservado su integridad y tanto Ana como Linus han sido autentificados el uno al otro y establecido un canal seguro cifrado. Si un tercero intentase de nuevo interceptar el mensaje de Ana, cualquier cambio que produjese en l destruira el hash del mensaje, Linus al descifrar el Hash de Ana comprobara que este no coincide con el Hash del mensaje, luego comprende que el mensaje ha sido comprometido y rechaza la comunicacin. El atacante podria redactar un nuevo mensaje, cifrarlo, calcularle el hash y firmarlo (encriptarlo con su clave pblica),

pero entonces Linus sabra perfectamente que la clave pblica necesaria para desecifrarlo no correspondera a la Ana!! Sino a la del atacante, con lo que jams la aceptara. Es aqu donde radica la importancia del crculo de seguridad, la necesidad de saber fehacientemente que una clave pblica pertenece a quien dice pertenecer. Este esquema PKI es bsicamente lo que se lleva a cabo en los sistemas de clave pblica PGP/GPG, pero ahora veremos las herramientas para el esquema SSL/TLS.

Certficado Digital Ahora s es la primera vez que lo nombramos. Un certificado digital no es ms que un documento, un archivo que identifica/asocia a un usuario con su clave pblica. Cuando veamos los repositorios de claves pblicas y realizbamos una bsqueda, cada entrada tena asociada un nombre, descripcin, clave pblica y firmas (los votos que hablbamos) de verificacin de otras personas. Un certificado es lo mismo (con algunos matices). El esquema PKI anterior (llamado Web of Trust) tiene el problema de la confianza, de la legitimidad. Es un buen paso hacia delante el firmar las claves ajenas para avalar su legitimidad, y est bien para trmites particulares, personales, encriptar archivos, correos a familias y amigos pero si una organizacin mundial, un gobierno, un particular o una empresa quieren garantizar que dicha clave pblica pertenece sin lugar a dudas a quien dice pertenecer, es necesario un sistema ms fiable. Es aqu donde aparece la Autoridad de Certificacin (CA). Se van a continuar firmando los certificados s, pero no por cualquier persona o grupo de ellas. Un certificado Digital asocia una serie de datos personales a una clave pblica, y ser un tercero, llamado Autoridad de Certificacin, quien garantice que esos datos corresponden a dicha clave pblica. Visto de otro modo, se trata de eliminar todas las firmas y sustituirla tan solo por una, una entidad, empresa, gobierno cuya firma tendr mucho ms valor que cualquier otra, dado que posiblemente se ha encargado previamente de verificar y asegurar que los datos son correctos. Los CA de mximo nivel se les llama CA races o root. Existen CA que delegan autoridad a otros CA secundarios para permitirles otorgar y firmar otros certificados. Esto se debe a la cadena de confianza. Yo como mxima autoridad certifico a una empresa como CA secundaria de la cual tengo plena confianza, permitindo

+le emitir y firmar certificados a ellos mismos. Si cualquiera quiere verificar un certificado emitido por un CA secundario o terciario, se realizar una verificacin ascendente, primero al CA superior, el certificado de dicha CA se verificar por el CA por encima hasta llegar al CA raz, el cual emite l mismo su propio certificado. Los CA son los que emiten los certificados, y al firmarlos les otorgan plena legitimidad dado que todos nos fiamos de ellos, dado que son la mxima autoridad de certificacin.

Podemos decir que los CA son tambin esas bases de datos de claves pblicas/certificados de cada usuario. Pero el CA no es la nica autoridad que existe. Por otro lado suele ser necesaria (no obligatoria) la presencia de la Autoridad de Registro (RA). El papel de un CA puede acabar aqu, y encargarse tan solo de la emisin y firmado. Muchas veces cuando se desea cotejar/verificar si un certificado es correcto, es el RA quien se encarga de verificar dicho certificado, siendo l el que conecta con el CA. Otra figura menos usada es la Autoridad de Validacin (VA), la cual tendra un papel similar, verificar si el certificado es vlido atendiendo a fechas de tiempo y otros datos. Aun as, como digo, lo normal es ir unificando las autoridades de verificacin, y de paso las comunicaciones son ms eficientes. As el mismo CA acta como RA y como VA. Hace unos aos los CA races eran muy pocos, lo que haca muy til estas autoridades intermedias. Cada vez son ms los CA races y los sistemas ms eficientes, siendo innecesaria la presencia de otras autoridades intermedias. Muchos de los lectores conocern el nombre de algunos de ellos, actualmente el listado de CA races debe de rondar las 90 entidades (sin contar con los CA estatales, como CA de pases, aunque estos no suelen considerarse como universales. Entre ellos los ms importante con diferencia son: VeriSign, Thawte, GoDaddy, GeoTrust, RSA Security Inc (la empresa) En los tiempos actuales, no es raro ver como gobiernos, grandes instituciones o multinacionales estn considerados tambin como CA, lo que sucede es que normalmente estos CA no emiten certificados a cualquier persona. Por ejemplo, el gobierno espaol tiene al menos dos Autoridades de Certificacin, la FNMT (certificados CERES) y La direccin General de Polica (Certificados para el DNI-e). Pero estas dos instituciones tan solo emiten certificados a los que tenemos nacionalidad espaola. Otro ejemplo de esto podra ser Intel o Microsoft. Ambos estn considerados como CA raz, pero no se dedican al negocio de los certificados digitales. Esto le permite a estas grandes multinacionales no depender de terceros, ahorrar costes y gestionar ellos mismos sus propios certificados, aunque evidentemente tan solo usan dichos certificados para ellos mismos, sus servidores, sus empleados quizs por eso podemos dividir estos dos grandes grupos como aquellos CA comerciales y aquellos que no lo son. Con esto, el esquema anterior PKI se modifica ligeramente y es el CA, el RA o el VA quien valida o garantiza la legitimidad del certificado. Hay que destacar que no existen dos certificados, uno que sea pblico y otro que sea privado. El certificado es tan solo el vehculo de la clave pblica. Es cierto que los certificados personales almacenados en el equipo se guardan con la clave privada junto a este, lo cual es completamente lgico, puesto que sin clave privada no podramos firmar o desencriptar. En realidad esto no es del todo cierto, dado que las claves privadas de estos certificados suele estar guardadas en un anillo de seguridad del sistema/equipo. Esto no obstante ocasiona un problema de seguridad importante dado que si alguien se hace con la clave privada, el sistema quedara completamente expuesto. Es por ello que cuando se requierer una seguridad avanzada, tanto certificados personales como las claves privadas, jams sern almacenados en un equipo, sino en soportes extrables como un pendrive (en el peor de los casos) o una SmartCard (Tarjeta Inteligente) en el caso ideal, o incluso un dispositivo TPM. Esto quiere decir que nuestra clave privada residir en nuestro DNI-e o tarjeta CERES o protegida adems por un PIN por si es extraviada o sustrada. Cuando se

requiere su uso es necesario un lector de tarjetas y el software adecuado para tomar de esta la clave privada y el certificado. El Certificado no solo indica el nombre y apellido de quien representa, sino que incluye informacin del CA que lo ha emitido, algoritmos de cifrado y hash que usa, fecha de revocacin, validez, tipo de certifiado toda esta informacin es necesaria. Por ejemplo el certificado de identificacin o cifrado de un servidor no tiene nada que ver con un certificado de cliente que podamos usar nosotros, o el certificado raiz de un CA es diferente a los otros dos. Por otro lado no todos los certificados se emiten para todos los propsitos. Lo normal es emitir los certificados con ciertas caractersticas. Por ejemplo, si se desea usar un certificado para cifrar correo electrnico ser necesario que el certificado especifique una direccin de correo, y este certificado quedar anclado a l. Otro buen ejemplo es un certificado con unas caractersticas concretas para el control de acceso de una empresa o para cifrar datos en un equipo. As, nuestro DNI-e por ejemplo tiene dos funciones principales, autentificacin y firma (hablaremos ms detenidamente del DNI-e en otro captulo). Vamos a ver unos certificados de ejemplos: Un certificado de un servidor para SSL/TLS (Gmail), un certificado CA raz (VeriSign) y un certificado personal para identificacin SSL/TLS, firma y cifrado de correo que no de datos (Mi Certificado CERES):

Hay que decir que estos datos son totalmente pblicos, cualquiera que acceda a gMail o descargue el certificado de gMail podr verlo. Firefox divide el certificado en dos pestaas. La primera es un resumen sobre el emisor, a quien representa y si el certificado es vlido para los propsitos marcados (en este caso el propsitos es para un servidor SSL). Recordar que cada vez que un certificado es usado, lo normal es verificarlo. Cmo? Verificando la firma de la entidad firmante. Podemos ver en la primera pestaa que el emisor es Thawte (que es el CA de dicho certificado), que est a nombre de Google Inc para la web mail.google.com (gMail). Se puede ver tambin la fecha, que aunque no hemos hablado de

ella es importante, ya que cuando se emite un certificado este suele tener un tiempo limitado. Tras el cual, el certificado pasa a ser revocado (anulado) y se emite otro (normalmente antes de que expire) con nuevas claves privadas y pblicas, esto se hace por seguridad evidentemente. La segunda pestaa desglosa completamente el contenido del Certificado. En caso de este certificado, Firefox nos muestra en la parte superior la jerarqua de CA que intervienen en dicho certificado, es decir la cadena de confianza. As, el certificado de google para mail.googl.com es emitido por el CA Thawte SGC CA. Este CA no es un CA raz, sino un CA secundario. El certificado de este CA a su vez es el que ha sido emitido por el CA raz Verisign Class 3 Pubblic. Por ltimo se muestra la clave pblica contenida en dicho certificado.

El primer certificado pertenece a un certificado raz de VeriSign, el mismo que estara arriba del todo del certificado de gMail para la web. En este caso el uso que se indica es el de Status Responder Certificate. Es decir, tan solo es usado prcticamente para atender a las peticiones OCSP que pueda recibir de sus CA secundarios, es decir verificar si los certificados estn o no revocados. En este caso no se considera un CA dado que el papel de verificacin de CA lo realizar el CA que est a su servicio. Este certificado raz fue el que emiti/valid el certificado de Thawate SGC CA, y es este ltimo quein actu realmente como CA del certificado de mail.google.com. El certificado CA intermedio ser por tanto realmente el que en su descripcin de uso rece: SSL Certificate Authority, puesto que el certificado Raz tan solo atiende a peticiones de revocaciones. Se puede observar que efectivamente es un certificado raz dado que el emisor (Issued By) y el destino del certificado (Issued to) no se encuentran presente, es l mismo emisor y destino, est firmado por l mismo.Si vemos la fecha por otro lado de expiracin, vemos un intervalo muy grande, un certificado ahora con ms de 14 aos de antiguedad, que usa un algoritmo de hash MD2, un hash ya muy antiguo. Por ltimo tenemos un certificado de CERES. He preferido poner este en vez del DNI-e porque este es ms til, tanto y cuando adems de poseer las caractersticas de autentificacin en internet (Cliente SSL), permite tambin la firma de correo (Email Signer) y su Encriptacin (Email Recipient). Podemos ver que el emisor es la FNMT, y dado que mi navegador tiene instalado el certificado Raz de estos y considerado fiable, el certificado de CERES lo es tambin, podemos leerlo arriba: This Certificate has been verified Por motivos de seguridad he eliminado mi nombre, DNI y esas cosillas.

Firma Digital En realidad poco ms o menos ya se ha comentado que es y cul es su utilidad. Cuando explicbamos una PKI, exponamos que cada clave pblica se votaba para que los otros usuarios pudiesen as garantizar que era legtima. Esto es realmente una firma. Una firma tiene la caracterstica de no repudio, es decir, una vez se ha firmado algo un usuario o una entidad no puede desquitarse de ello, dado que la firma lo identifica a l de forma irreversible, sin que este pueda negar que lo ha hecho. Las firmas digitales usan de forma conjunta dos tecnologas, la inviolabilidad de un sistema de cifrado asimtrico tipo RSA y la integridad de datos que ofrece un Hash criptogrfico como SHA-1 o MD5. Si un usuario desea cifrar un documento o un mensaje para que tan solo podamos ser capaces de descifrarlo nosotros, tan solo tiene que cifrarlo con nuestra clave pblica, y tan solo nosotros poseedores de nuestra clave privada podremos descifrarlo. Pero esto puede usarse de manera inversa. Si yo cifro algo con mi clave privada, la clave pblica lo descifra. Dado que todos tienen acceso a mi clave pblica, todos pueden descifrar aquello que yo cifre con mi clave privada. Pero entonces para que vale esto? Porque un certificado garantiza la asociacin de una clave pblica a una persona fsica. Luego quien descifre algo con mi clave pblica obtendr un contenido que tiene la certeza fue cifrado solo por m. Y por parte del Hash, otorga integridad al mensaje. El proceso es simple:

a) Se calcula un Hash criptogrfico al mensaje, documento a firmar, por ejemplo un Hash SHA-1. b) Ahora se encripta por medio de nuestra clave privada dicho Hash, lo cual obtenemos un Hash cifrado. c) A partir de este momento, al documento se le incrusta (adjunta) la firma. El destinatario, se topar con que existe una firma de dicho documento, con su certificado pblico correspondiente, y por supuesto con las validaciones pertinentes. El destinatario puede descifrar el hash y obtener el Hash que asegur el remitente que era el idneo. El destinatario calcula el mismo Hash al mensaje recibido. Si los dos Hash coinciden, el destinatario comprende que el mensaje es legtimo y que no ha sido modificado de ningn modo. Una forma digital puede usarse para varias tareas. Por ejemplo, evidentemente como sustituto natural de nuestra firma fsica. No obstante ya hemos hablado que se usa para los certificados. Los certificados que nos emiten los CA deben de estar firmados por estos. La firma de estos en nuestro certificado funciona del mismo modo. Cuando se verifica un certificado, entre otras cosas como comprobar la fecha de validez o las listas de certificados revocados, se verifica que la cadena de confianza es correcta. Esto que implica? Ir verificando uno a uno todos los certificados implicados en un certificado. Esto es verificar la firma del firmante de nuestro certificado, lo cual para ello es necesario verificar que el certificado de este CA est firmado por otra CA que sea igualmente vlido as hasta llegar al CA raz. Si en cualquier lugar de la cadena falla la verificacin, la cadena entera se rompe y el certificado no puede garantizarse como seguro. Otro uso comn es la firma de un cdigo. Esta es una prctica cada vez ms expandida en el mundo del software. Un mtodo de proteger un sistema operativo frente a ataques, como pueda tener Windows Vista o Windows 7, es que los drivers deben de estar firmados obligatoriamente por Microsoft (en este caso), de forma que esto garantiza que los drivers no son dainos y son legtimos. Esto puede verse tambin en las partes ms crticas del sistemas, en las que los archivos o el contenido ms sensible para el correcto funcionamiento del sistema se firma de forma que el propio sistema no permite su ejecucin si la firma no es vlida. El problema que ocasiona esto no obstante es que se puede hacer un uso intensivo de esto para evitar la libertad. Por ejemplo el iPod Touch/iPhone, en el que cualquier contenido que se desee ejecutar, debe de estar obligatoriamente firmado por Apple, si no lo est no se puede ejecutar. Esto implica que (sin JB) tan solo las aplicaciones aprobadas del AppStore pueden ser usadas, al margen de que pudiese ser posible o no instalar otro tipo de aplicaciones, al margen del degradamiento de rendimiento por tener que estar continuamente verificando las firmas. Desde mi punto de vista la diferencia del buen uso y el abuso es la intencionalidad. Proteger con una firma una bios o un bootloader tiene un sentido muy simple, es una parte crucial del sistema y cualquier virus o modificacin daina producira que el sistema sea inutilizado, lo cual implica que es positivo. Pero debera de ser una opcin, no una obligacin. Por ejemplo, se dijo mucho sobre los drivers de Windows x64 y que nadie podra crear drivers para ellos dado que todos tienen que estar firmados por Microsoft. Esto no es tampoco tan as. Se pueden instalar drivers firmados por uno mismo si se quiere, lo que pasa es que el sistema nos advertir sobre la procedencia del certificado y categorizar el driver como no seguro, avisndonos del peligro que ello implica. Pero a fin de cuenta la libertad es del usuario.

Lo habitual por tanto es ver una firma digital como un documento adjunto en un correo (extension p7s), incluida en el mismo cuerpo del mensaje en el caso de usar PKI como PGP/GPGo como un aadido a un documento. Al final del todo veremos aplicaciones prcticas de todo ello de todas estas cosas. De cara a un gestor de correos o cualquier otro programa que acepte contenido firmado, simplemente sabr como interpretarlo y verificar dicho contenido.

Visto todo esto podemos hacernos una imagen de lo que es un certificado digital y la firma electrnica: a) Ana descarga el certificado de Carmen, lo ha descargado del servidor LDAP de la empresa (o de la web de Carmen). Al instalarlo en su equipo (y sin que ella lo sepa) el certificado de carmen es comprobado. Dado que el certificado de Carmen est firmado por VeriSign, el equipo de Ana tan solo tiene que verificar que la firma de VeriSing es vlida. Dado que el certificado raiz de VeriSign est incluido en el equipo, el equipo de Ana desencripta la firma de Verisign del certificado de Carmen con la clave pblica que se encuentra en el certificado raiz de VeriSign. El equipo de Ana obtiene as el Hash del certificado de Carmen, el cual coincide a la perfeccin con el propio certificado, luego Ana est convencida de que el certificado que tiene en su poder es sin duda el de Carmen. b) Ahora que Ana est convencida, redacta el mensaje y lo encripta con el certificado de Carmen y lo firma con su clave privada. Lo enva a Carmen. C) El mensaje llega a Carmen y lo primero con lo que se topa es la firma. El gestor de correo busca la clave pblica perteneciente a dicho correo electrnico accediendo posiblemente al repositorio del CA emisor y el nombre y apellidos de Ana. Carmen no se fia de que sea Ana, pero el certificado que ha encontrado efectivamente tipifica dicho correo electrnico y dichas credenciales, y est emitido y firmado por la FNMT (se verifica la firma de la FNMT, que a su vez verifica el certificado de Ana). Cuando est seguro del certificado de Ana, desencripta la firma con l, dado que la clave pblica de Ana desencripta el hash que fue encriptado con la clave privada de esta. Carmen verifica la firma y con su clave privada desencripta el mensaje y lo lee.

Aplicaciones prcticas Autentificacin

de

la

Criptografa

la

Todo lo que hemos explicado anteriormente tiene un fin: Usarlo. Hasta ahora tan solo hemos visto la teora que se esconde detrs de un algoritmo de cifrado de datos o un hash, que es un certificado o una firma digital. Comprendo que no es una parte muy ldica para aquellos que les gusta la accin, pero en cambio es necesario la comprensin de este tipo de conceptos para poder usarlos. Y es que no son pocas las aplicaciones prcticas de todo lo que se ha explicado, de echo la seguridad actual de la red depende de ello. As que vamos a ver como usamos realmente todo esto:

Encriptacin de archivos en disco: Simple, Unidad completa, TPM, EFS, BitLocker. SSL/TLS

OpenPGP/GPG Correo Electrnico: S/MIME y GPG Firmas

La idea es evidente, usar todo lo citado anteriormente para efectivamente cifrar y asegurar nuestros datos o nuestras comunicaciones. Aunque la idea principal es la misma siempre: proteger, cada elemento que deseemos proteger o aut entificar emplear posiblemente un sistema diferente.

Encriptacin de archivos en disco As, el punto de partida casi con toda seguridad sera la encriptacin de archivos en nuestro propio disco duro. Es evidente que si tenemos informacin sensible en nuestro equipo, podemos desear que esta est cifrada para que sea imposible su lectura. Imaginar equipos compartidos, o en entornos mucho ms clsicos como el cifrado de datos de material secreto en empresas y similar. Evidentemente si nos referimos ya a la informacin sensible que puedan tener gobiernos, instituciones o grandes empresas, el uso es ya obligado, nadie quiere que alguien pueda acceder al sistema y robe informacin que est desprotegida. Es mucho ms eficiente tener la informacin sensible a buen recaudo. Visto esto, no todos los modelos de cifrado de dato pueden ser deseables. Lo primero que habra que pensar sera que tipo de archivos se desea encriptar, y si se desea hacerlo de forma simtrica o asimtrica. La filosofa de nuevo difiere en lo que deseemos. El uso ms bsico por ello sera el cifrado de archivos individuales. Si aplicamos la lgica de lo visto anteriormente, que tipo de cifrado parecera ms lgico aplicar aqu? Posiblemente el Cifrado simtrico. En estos entornos, no solemos necesitar que dicho archivo sea accedido por un milln de personas, todo lo contrario!! En el caso ms simple tan solo nosotros deseamos tener acceso al original, luego el cifrado simtrico no parece ser una desventaja. Por otro lado el cifrado simtrico es mucho ms rpido, y posiblemente en este caso los archivos a cifrar sean desde pequeos archivos a grandes archivos. Si optamos por tanto por un sistema de cifrado simtrico podramos pensar ahora mismo en AES-128 por ejemplo (o AES-192, AES-256). Como dijimos en su momento, no solo es importante seleccionar el algoritmo de cifrado, sino que en el caso del cifrado simtrico es imprescindible la eleccin de un modo de tratamiento de bloques efectivo, para evitar lo sucedido. entre otras cosas. lo que se pudo observar con las imgenes. De este modo poco a poco podemos ir haciendo una idea de lo que necesitamos, AES-192 y CBC. Esto no significa que no pudiese hacerse de otro modo. Se podra cifrar perfectamente un archivo con cifrado asimtrico o usar otros algoritmos de cifrado simtrico.

Una vez tenemos claras las necesidades tan solo nos restara tener un software para realizar el cifrado y el descifrado. Actualmente existen cientos de miles de programas para ello, de pago y gratuitos. Algunos soportan un gran rango de algoritmos, otros son ms restrictivos. En nuestro caso vamos a usar de forma didctica CrypTool. Amn de ver los diferentes resultados, el texto de este archivo y de todos los ejemplos que vamos a ver ser siempre el mismo, con un tamao de 161 bytes: Esto es un archivo de ejemplo para encriptar. Podra no ser un archivo de texto y ser un archivo binario, no hay lmites en el contenido a cifrar ni en su tamao Usando CrypTool, sera necesario crear primero u esquema de cifrado, despus configurarlo y despus aplicarlo: Como vimos en otro captulo, comenzando por un archivo de texto plano con el texto especificado, se pasa por un cifrado AES-192 CBC. En este punto el destino se guarda en un archivo llamado Cifrado.txt (que pertenece al mdulo Cifrado) y otra salida se vuelve a pasar por AES-192 CBC (en este caso para desencriptar), obteniendo a la salida un archivo llamado Descifrado.txt. En teora si el cifrado y descifrado es correcto, el archivo original llamado A cifrar.txt con el texto antes especificado, debera de coincidir con el archivo Descifrado.txt byte a byte. Antes de mostrar la salida de los datos, me gustara explicar brevemente BASE64: BASE64 es un sistema de codificacin ampliamente usado sobre todo en la transmisin de datos. La idea es poder convertir cualquier tipo de dato en un texto plano. De este modo se puede dar una interpretacin escrita de cualquier archivo binario si se desea. Bsicamente 3 bytes binarios se convierte a 4 Bytes en BASE64. Se sacrifica tamao, pero se gana en facilidad de manejo de los datos, dado que de este modo pueden tratarse como simples cadenas de texto. Quizs no sea la primera vez que lo exponemos aqu, pero s que ser usado. Si quiero mostrar el resultado encriptado del ejemplo anterior, me vera obligado a mostrarlo en hexadecimal, dado que no todos los valores hexadecimales tienen una correspondencia a carcter escrito. No obstante, si puedo convertir el archivo encriptado o el archivo desencriptado a Base64 y mostrar el contenido, contenido que puede posteriormente si se desea revertirlo a binario. Terminado este parntesis, en este ejemplo cabe destacar dos cosas. La primera es comprobar si el archivo de origen es igual al archivo final desencriptado. Si no fuese igual el cifrado no sirve. No obstante si verificamos el contenido del archivo Descifrado.txt se puede leer el mismo texto aunque este no tiene 161 Bytes de tamao, sino 176 Bytes, es decir 15 bytes ms. Que ha pasado?. Si comprobamos el archivo Desencriptado.txt en un editor hexadecimal, comprobamos que por una extraa razn, al final del archivo se le ha aadido 15 Bytes con el contenido ox00:

Como podemos ver, parece ser que no ha sido desencriptado correctamente. Si acudimos al archivo cifrado vemos que Cifrado.txt tiene una longitud tambin de 176 Bytes, luego el problema parece encontrarse en la codificacin. Que ha sucedido? El Padding. Recordemos que enun cifrado pro bloques, cuando no hay ms datos para rellenar el bloque es necesario rellenarlo con otros datos. El Padding que fue configurado en CrypTool fue precisamente el relleno de ceros. El relleno de ceros es el ms simple de comprender, pero no es el ms eficaz, ya que a la hora de reconstruir el archivo original es imposible conocer cuantos bytes fueron aadidos, y por ello obtenemos el resultado anterior. Si se hubiese escogido un Padding mejor, podra haberse evitado esto. De donde salen estos 15 Bytes ms? Es simple. AES usa un tamao de bloque de 128 Bits. 161 Bytes * 8 = 1288 Bits. Si los debemos de tomar en bloques de 128, nos deja con 10 bloques completos y 8 bits de pico. Por tanto es necesario rellenar el bloque de tan solo 8 bits para completar los 128: 128-8 = 120 Bits /8 = 15 Bytes. Es decir, para poder completar el ltimo bloque es necesario incluir un padding de 15 Bytes. Por otro lado, si mostramos el contenido binario del archivo Encriptado.txt (sin usar esta vez la conversin a Base64 y usando mejor una imagen), esto es lo que obtenemos:

A esto nos referamos con que una conversin a BASE64 resulta muy til. No podra aunque quisiese exponer el contenido de la derecha, es decir, el contenido interpretado del archivo binario. Las soluciones pasan por expresarlo en hexadecimal (la parte de la izquierda) o expresarlo en BASE64. Normalmente es mejor expresarlo en formato base64 por el motivo que he dado, a la hora de manejar en las comunicaciones los datos, es mejor que estos estn expresados como un texto plano. As, el texto descifrado expresadoen base64 sera el siguiente:

Da igual que fuesen caracteres no imprimibles, al convertirlos a Base64 podran ser representados en pantalla, y es por ello que esto se usa extensamente. Cuando hablemos del correo electrnico, Base64 ser algo comn.

Por otro lado no solo existen tcnicas para cifrar un solo archivo. Se podra realizar la misma tcnica explicada pero en vez de introducir un archivo de entrada, introducir 200 archivos, 1000 archivos incluso una unidad completa. El cifrado individual de archivos se ha quedado un poco en desuso, y actualmente tan solo se usa para transmisin de archivos puntuales o material sensible espordico. Esto ha ido evolucionando y la prctica ms generalizada actualmente pasa por el cifrado de una unidad completa Ahora no buscamos la proteccin de un archivo concreto, sino de todo lo que se encuentra en la unidad. Esto evidentemente otorga un ndice de proteccin bastante alto, dado que todo lo que se realice en dicha unidad estar siempre protegido. Si dicha unidad fuese sustrada, nuestros datos se encontraran completamente a salvo. En un primer momento podramos pensar que este esquema sera exactamente igual que el anterior, pero no es as. La idea es que el contenido accedido se desencripte en el momento de acceder a dicho contenido, y sea encriptado en el momento que se realice alguna modificacin. Es evidente que este tipo de esquemas podra reducir las prestaciones de un equipo, dado que se estara encriptando y desencriptando constantemente. Actualmente existen algunas soluciones para realizar esto. Existe multitud de software de terceros para permitir la encriptacin de volmenes completos, aunque vamos a centrarnos en herramientas que podemos encontrar ya en nuestro propio sistema: EFS o BitLocker. El problema con el cifrado completo de una unidad es como hacerlo. Realizar un cifrado completo de una unidad es facil, pero como se gestiona para que se pueda hacer en tiempo real? Para nosotros es imprescindible que la tarea sea llevada a cabo de forma transparente.

Por un lado tenemos EFS, Encryption File System que est disponible en Windows desde Windows XP. Con EFS se encripta cada archivo que es escrito en el HDD y se desencripta cuando se requiere. EFS usa un sistema hbrido entre cifrado simtrico y cifrado asimtrico, cosa que veremos es muy comn uusar. El sistema es simple, cada archivo se cifra con una key por medio de cifrado si mtrico. Esta key ser diferente a cada archivo, con lo que aun cuando un ataque pudiese recuperar la key de un archivo, esta no sera de mucho valor, dado que tan solo servira para ese archivo. Implica que el sistema guarda una base de datos con todas las keys, una por cada archivo? No, es ms eficiente. Lo que se realiza es cifrar la key usada por cada archivo por medio de cifrado asimtrico, y una vez cifrada se adjunta al propio archivo. Es decir, cada archivo cifrado incluye la key usada para desencriptarlo, claro que antes hay que desencriptar la key por medio de la clave privada del cifrado asimtrico. Comprometer un cifrado asimtrico es mucho ms complicado e imposible que el cifrado simtrico. En el peor de los casos en el que el archivo pudiese ser atacado o recobrada su Key, esto no pondra en peligro ni a la clave privada ni al resto de archivos. Para realizar este sistema, Windows asocia a la sesin del usuario la clave privada requerida para desencriptar las keys individuales de cada archivo. A lo largo de los aos, con la aparicin de Windows Vista y Windows 7, el cifrado asimtrico RSA se ha sustituido por un sistema de Curva Elptica, otra matemtica imposible que tiene ventajas e inconvenientes respecto RSA, a fin de cuenta otro sistema de cifrado asimtrico. Por otro lado se ha permitido poder guardar una key maestra en un dispositivo extraible, desde un pendrive a una Smart Card. Esto quiere decir que no hace falta recordar una Key (a menos de querer crear una de recuperacin) para usar EFS. Para usar EFS tan solo basta con ir a las propiedades de un archivo o carpeta y marcar la opcin cifrar. Cuando una carpeta o un archivo sea marcado como cifrado, desde nuestro punto de vista, mientras nuestra sesin est activa dicho archivo ser completamente accesible por nosotros del modo habitual. En cambio si se intentase acceder a dicho archivo desde otra sesin o desde otro equipo, dicho archivo/carpeta sera completamente inaccesible. Un paso ms all se encuentra BitLocker, disponible tan solo en algunas ediciones de Windows Vista y Windows 7. BitLocker es un sistema anlogo a EFS, aunque ambos pueden ser usado conjuntamente. BitLocker es un sistema que puede cifrar una unidad lgica. BitLocker no cifra archivos por as decirlo, sino la unidad lgica completa deseada por medio de AES en modo CBC, por ello es posible usar EFS en conjuncin con l. BitLocker funciona no solo a nivel del propios OS, sino que tambin protege los sectores de inicio. Si Bitlocker detecta un cambio de bios o una modificacin en cualquiera de sus elementos como el bootloader, este no desencriptar la unidad lgica, y por ende el sistema no arrancar de ninguna de las formas. Es una capa de encriptacin que se coloca por encima del propio OS, siendo Bitlocker el primer elemento en procesarse en el arranque del sistema, como hemos dicho incluso antes de que el propio kernel de Windows sea cargado en memoria. El mtodo de funcionamiento es simple, nada mas arrancar el sistema, este verifica si todo el boot es correcto o ha sufrido alguna modificacin. Si todo es correcto solicita la Key para

poder permitir el acceso a la unidad lgica. Si detecta algn cambio en el boot, bloquear el sistema y obligar a la introduccin de una Key de conformidad que verifique los cambios efectuados en dicho Boot. Esto produce dos cuestiones interesantes: Que tipo de subsistema se arranca para que bitlocker se ejecute y como accede bitlocker a las keys. Para poder usar BitLocker, el sistema debe de generar una particin de pequeo espacio que ser la que arranque el sistema, dicha particin no podr estar encriptada claro est, es tan solo como un subsistema para que bitlocker pueda trabajar de forma correcta. Pero queda el otro problema o ventaja. Como se suministra la Key? En un principio BitLocker requera del uso de un TPM. En Windows 7 es posible usar BitLocker suministrando la key desde un pendrive externo. TPM? TPM son las iniciales de Mdulo de plataforma segura. Bsicamente es un hardware criptogrfico que tiene algunas funciones interesantes. En primer lugar acta como un acelerador por hardware ya que en su hardware es posible computar hashes o firmas. Por otro lado permite que las creaciones de claves privadas y pblicas sean generadas en su propio interior y que estas no sean jams exportadas al exterior. Si se requiere la clave privada el usuario a travs normalmente de un PIN dar acceso al mdulo TPM de usarlas. A fin de cuenta es mucho ms seguro que nuestra Key privada de nuestro equipo est almacenada en un hardware que en cualquier otro medio. Incluso si el mdulo TPM es sustrado, aunque en teora sera posible de extraer las key del mdulo TPM en la prctica esto es imposible, de ah a su seguridad. De este modo el usuario no tiene que preocuparse de Keys, de tener que transportarlas ellos mismos. Una vez que se habilita BitLocker y la particin es creada, el Hardware TPM se inicializa, se crean las claves necesarias y se comienza con el cifrado de la unidad lgica. Como he dicho en Windows 7 no es necesario por obligacin el uso de un mdulo TPM, pudiendo usar en su defecto (mucho ms inseguro) un pendrive. BitLocker en Windows 7 se le aadi la opcin de poder proteger no solo una unidad del propio sistema, sino unidades extraibles. Una caracterstica que se ha criticado a Microsoft en BitLocker es la no inclusin a sabiendas de algn tipo de puerta trasera que permitiese el acceso al sistema aun cuando fuese cifrado con BitLocker. Esto apareci no hace demasiado, donde autoridades inglesas denunciaban a Microsoft que BitLocker podra ser usado por pederastas en unidades externas para proteger pornografa infantil y otro tipo de contenidos, de modo que no fuese posible la recuperacin de estos datos. Para usar las caractersticas de BitLocker tan solo es necesario acudir al panel de control y acceder a BitLocker:

El almacenaje en Smart Card es una prctica muy comn, suele ser seguro y adems por regla general suelen poseer de hardware criptogrfico propio, lo que hace de estos soportes ideales para muchas de estas tareas. Un ejemplo simple de Smart Card criptogrfico es el propio DNI-e, el cual contiene los certificados y claves dentro de l. Podemos decir sin lugar a duda que un Sistema Windows 7 empleando tecnologas como BitLocker y EFS conjuntamente con un mdulo TPM supone un sistema muy seguro ante cualquier tipo de intento de robo de informacin. Esto no quiere decir que no sea posible atacar un sistema similar para acceder a l, pero s que puede poner las cosas ms que complicadas a cualquiera que lo intente.

SSL/TLS SSL/TLS son protocolos de seguridad para permitir una conexin segura entre cliente y servidor. Esto es posible gracias a los sistemas criptogrficos explicados: Cifrados Asimtricos, Simtricos y Hash. De forma generalizada casi nadie usa el trmino TLS, e indistintamente se hace eco de SSL para especificar tanto SSL como TLS. No obstante, SSL es un protocolo antiguo y que ha demostrado tener algunos fallos de seguridad, el cual fue sustituido por TLS. Aunque TLS no es compatible con SSL, TLS si tiene inclua una

funcionalidad de poder usar SSL en caso de que la conexin TLS no sea posible por la razn que sea. Por ello apartir de ahora y para evitar palabrera, usar TLS en todo momento. Actualmente SSL3 se considera seguro, aunque es mejor usar TLS 1.0/1.2 en la medida que sea posible. TLS es usado en un sin fin de aplicaciones diferentes. Por ejemplo es usado para autentificar y/o cifrar contenido de cualquier web por medio de HTTPS, pero tambin es usado para asegurar (encriptar y autentificar) las conexiones de correo electrnico (que no es lo mismo que decir que se enva un correo cifrado, lo que se cifra es todo el contenido de la sesin, aunque incluya el propio correo, es muy diferente). Sea como sea, su funcin principal es garantizar una conexin segura entre dos puntos de la red cualquiera, sin preocuparse de que cualquier posible atacante pueda interceptar la comunicacin o modificarla, cosa ms que necesaria para transacciones bancarias, transmisin de datos personales, lectora de correo en redes no seguras TLS es un sistema hbrido, al igual que vimos con EFS. TLS se basa bsicamente en encriptar el contenido de la conexin por medio de un cifrado simtrico a negociar, cuya key es transmitida desde el cliente al servidor encriptada gracias a la encriptacin asimtrica. De este modo, de lograr interceptar o descifrar una comunicacin, tan solo sera perjudicial para dicha conexin dado que cualquier otra conexin usara una key diferente. Es decir, TLS se apoya en el uso de certificados digitales. Aunque esto es a groso modo el funcionamiento de TLS, cabe destacar que una sesin TLS tiene dos modos de funcionamiento. El primero y ms extendido, tan solo se requiere la autentificacin del servidor frente al cliente. En el segundo esquema, tanto el servidor como el cliente se deben de autentificar mutuamente. Vamos a ver los pasos que se realizan en una conexin TLS: 1. El cliente solicita una conexin segura, y enva al servidor una lista de los cifrados y hash que el navegador soporta, as como un nmero aleatorio y la versin del protocolo que desea usar. 2. El servidor responde con la versin de protocolo que se usar en relacin con la recibida por el cliente, as como el mtodo de cifrado y hash que se usar. Evidentemente el servidor seleccionar el cifrado, hash y versin de protocolo mayor que soporten ambos. 3. El servidor enva a continuacin su certificado al cliente. El cliente comprobar la validez del certificado, comprobando su firma y el CA correspondiente. 4. El servidor solicita al cliente que enve su certificado. 5. El servidor indica que ha finalizado por su parte toda la negociacin. 6. El cliente enva su certificado al servidor, y este lo verificar comprobando su firma y el CA correspondiente. 7. El cliente enva al servidor una prekey cifrada con la clave publica del servidor. 8. El cliente firma (hash y encriptar con su clave privada) los mensajes de negociacin previos. El servidor verificar esto con la clave pblica del cliente. 9. El cliente y el servidor generan la Key para el cifrado simtrico que van a usar gracias al nmero aleatorio generado al comienzo y a la prekey 10. El cliente enva un mensaje de finalizacin cifrado conteniendo el hash de los mensajes de la negociacin y otros datos. 11. El servidor descifrar el mensaje y validar los hash

12. El servidor enviar u mensaje de finalizacin cifrado conteniendo el hash de los mensajes de negociacin y otros datos. 13. El cliente descifrar el mensaje y los validar. Lo que est en otro color es tan solo vlido para aquellos sistemas en los que es indispensable la autentificacin del cliente de cara al servidor. En el paso 8, el servidor garantizar que el certificado que ha recibido corresponde al cliente con el que est negociando la conexin segura. Si la clave pblica obtenida del certificado del cliente puede descifrar la firma realizada por el cliente, autentifica al cliente como vlido. Si en cualquier paso una verificacin es fallida, un hash no corresponde al que debera de corresponder o cualquier otra circunstancia, se supone que no se ha podido establecer una conexin segura y se aborta la negociacin. En cambio, si se llega al paso nmero 13, a partir de ese momento toda la comunicacin realizada entre cliente-servidor ser una conexin autentificada y segura. Incluso los pasos del 10 al 13 son pasos de la negociacin ya cifrados mediante cifrado simtrico. Aqu el uso que se le da al cifrado asimtrico es relativamente pequeo, tan solo es usado en la propia negociacin. Gracias a un Sniffer es posible verificar que este es efectivamente el esquema de uso de TLS:

En dicha imagen podemos ver los pasos que se han ido realizando. En este caso es una comunicacin desde un cliente de mi red (192.168.2.2) a gmail (209.85.227.83). Asi, mi paso nmero 1 corresponde al paquete nmero 4 de la imagen: Client Hello. El paso nmero 2 al paquete 6 Server Hello. El paso nmero 3 y el nmero 5 son realizados en el paquete 7 con Ciertificate y Server Hello Done. En este caso no hay autentificacin por parte del cliente. El paso nmero 7, 9 y 10 son realizados en el paquete nmero 9 con Client Key Exchange, Change Cipher Spec y Encrypted Handshake Message, y los pasos 11, 12 y 13 en el paquete nmero 10 Encrypted Handshake Message, Change Cipher Spec y Encrypted Handshake Message. En sucesivos paquetes, todo el trfico ir cifrado. Si passemos a analizar cada uno de esos paquetes, podramos ver con mucho ms detalle cada paso realizado. Por ejemplo, el mensaje Client Hello en el cual el cliente especifica los cifrados disponibles y soportados por el navegador, as como el nmero aleatorio:

Como podemos ver prcticamente todos los algoritmos que han aparecido los hemos tratado. Dentro del cifrado asimtrico es usado RSA y EC (Curva Eclptica). EC aqu se aplica a diferentes sistemas, por ejemplo ECDHE (Diffie-Hellman Exchange es un sistema de intercambio de claves para realizar un cifrado simtrico). Dentro de los cifrados simtricos podemos ver AES-128, AES-256, RC4-128, Tiple DES , Camella y SEED (estos dos ltimos no se han visto). Para acabar, dentro de los Hash tenemos SHA y MD5. DSA por otro lado es un algoritmo de firma digital. Hay que tener en cuenta que TLS puede ser usado en un sin fin de aplicaciones diferentes, con lo que es normal ver en la lista de algoritmos soportados algunos que podran no tener mucho sentido a priori en ellos

Y por parte del servidor podramos ver igualmente tanto el certificado enviado como los ajustes seleccionados. El certificado no sera ms que el certificado, la respuesta en este caso de Gmail ante nuestra peticin sera:

Es decir, ante todas las sugerencias del cliente, el servidor opta por seleccionar el protocolo TLS 1.0 (dado que es el mximo que soporta el navegador) y responde que usar el conjunto de cifrado RSA para el cifrado asimtrico, AES-256 para el cifrado simtrico en modo CBC y los Hash sern SHA. Como hemos dicho, TLS es una negociacin. Significa que estos datos dependern del equipo del cliente y del equipo del servido. Posiblemente si realizamos una conexin a Gmail dede IE, la lista de cifrados sea diferente, quizs aparezca alguno ms quizs alguno menos. TLS no deja de ser a fin de cuentas un estndar, si se requiere que un navegador fuese 100% compatible debera de ser compatible con el 100% de los cifrados y sistemas propuestos en el estndar, pero esto es la teora, no la prctica. De todos modos la prctica dice que los servidores TLS ms seguros usan por regla general RSA+AES-256+SHA, mientras que los ms inseguros pueden usar aun DES o Triple DES como cifrado simtrico y MD4 o MD2 para el hash. Lo ms normal es encontrar RSA como cifrado asimtrico y RC4 o AES como cifrado simtrico. Vamos a comparar la peticin realizada anteriormente con Firefox a Gmail con la que expondremos a continuacin entre IE y Live:

En este caso de los 36 sistemas de cifrado soportado por Firefox, tan solo son 12 los soportados por IE. Y la respuesta de Live frente a esto:

Es decir, el servidor de Microsoft Live seleccioan como su mejor opcin el uso de RSA con RC4-128 y MD5. Es decir, el sistema usado en TLS por parte de los servidores de MS para Live es mucho ms inseguro. A fin de cuentas RC4 a resultado ser relativamente vulnerable, y MD5 es tambin ms inseguro que SHA. Esto no quiere decir que no sea un sistema seguro, pero s que es mucho menos seguro de la seguridad que puede ofrecernos Gmail. TLS es un protocolo muy seguro. Normalmente no es posible comprometer este tipo de sistema, y cuando se ataca no se ataca normalmente a intentar descifrar las claves, sino algn fallo del propio protocolo. Hoy por hoy la mayora de todas las comunicaciones sensibles hacen uso de una manera u otra de TLS. Se usa para cifrar el contenido en la web por medio de HTTPS, el correo por medio de SMTPS, tneles VPN Podramos incluir aqu STARTTLS. En realidad STARTTLS es un protocolo que se ve en Email Spoofing. SSL/TLS usan puertos especficos en los servidores. Por ejemplo por regla general, las peticiones HTTP se realizan al puerto 80 de los servidores, mientras que

las peticiones HTTPS (usando TLS) al puerto 443. En el correo pasa algo similar. Para el correo SMTP se suele mapear al puerto 25, y 995 para TLS. STARTTLS se propuso para poder realizar la conexin por el mismo puerto no seguro (25), y una vez realizada la conexin al servidor se realizara el cambio a usar TLS. Cuando se usa TLS toda la comunicacin ntegra es cifrada, con STARTTLS tan solo cuando se llama a este protocolo, siendo posible la conexin e incluso su uso de servidores de correo que usan STARTTLS, si no estn configurados para requerir despus del mensaje de HELO el cmando STARTTLS. Desde mi punto de vista, todo contenido que pudiese ser de carcter personal debera de ir bajo conexiones seguras. Por desgracia muchos administradores no comportan esta filosofa, y tan solo se preocupan en todo caso de cifrar por medio de TLS las credenciales de acceso de un lugar, dejando desencriptado todo el contenido al que se est accediendo. Esto lo veremos cuando tratemos el fascinante mundo del Sniffing en otros temas, no ser tratado en Encriptacin y Autentificacin. Lo que si debe de quedar claro es que no por usar un sistema como TLS podemos asegurarnos de que todo est protegido, nada ms lejos. Y esto es muy muy importante. Que los certificados deban de estar firmados por autoridades CA reconocidas, no implica que estos no puedan ser usados en otro tipo de entornos en los que la firma de un CA famoso no es necesaria. Seamos francos, los certificados digitales suelen costar dinero, debes de acudir a un CA para que certifique tu identidad y te lo extienda. Pero sera esto necesario para asegurar las comunicaciones dentro de una empresa? La respuesta es no. Un CA es necesario para dar validez a un certificado de manera global, pero cualquier usuario puede en cualquier momento crear un certificado de la clase que sea (Servidor SSL, Cliente SSL, Firma) para el fin que necesite. Es evidente que si este certificado es expuesto al exterior y un tercero tiene que hacer uso de l, posiblemente su navegador le advierta del peligro que ello entraa, dado que casi con toda seguridad el navegador del usuario no pueda verificar la firma del CA, dado que el CA posiblemente no est reconocido por su navegador como un CA vlido. Es decir, lo que realmente dicta si un certificado es de confianza o no es a fin de cuentas la firma del CA. Si el navegador o el sistema tiene el certificado del CA reconocido como confiable, el certificado ser igualmente confiable. Esto implica que una empresa puede crear un certificado CA propio, y a partir de este crear los certificados que necesite para los propsitos que sean: Servidores Web, Certificados para los trabajadores para que puedan firmar o cifrar el correo, Certificados para el acceso a los equipos informticos, Certificados para las Smart Card para el control de acceso a las instalaciones, Certificados para el cifrado de los datos de los equipos, Certificados para asegurar las conexiones VPN Y todos ellos estaran firmados por el certificado raiz de la propia empresa. Si dichos certificados se usan fuera de la empresa, simplemente los sistemas exteriores o los navegadores, gestores de correos no podran simplemente poder validad el CA. Pero para la propia empresa, esto no sera jams un problema, dado que sus sistemas tendra reconocido el certificado CA de esta como legtimo. La creacin de certificados para uso personal es realmente til. Dado que pueden ser usados en un sin fin de utilidades, cuando queremos usarlos nosotros para nosotros no nos

preocupa lo dems, no deseamos interaccionar con un tercero, simplemente asegurar nuestros sistemas. Esto es usado muchsimo, incluso en servidores Web particulares en los que no se desea comprar un certificado, dado que los precios pueden ser relativamente altos para un particular. El problema? Como se ha dicho, los navegadores, gestores de correos y otros suelen verificarlos, y como se ha dicho, si el CA no lo tienen como un CA vlido, aparecer una pantalla de advertencia. Hay que tener en cuenta que estas pantallas de advertencias de seguridad de certificado no vlido son para tomarse muy en serio, aceptar un certificado no vlido maligno supondra que un tercero podra estar comprometiendo toda nuestra comunicacin. Un ejemplo de advertencia de seguridad de certificado en Firefox sera tal que as:

Por alguna razn, Firefox nos advierte de que la pgina a la que se est accediendo tiene un error con el certificado. Si expandimos Technical Details nos reporta el por qu el acceso a dicha web ha sido bloqueado, en este caso porque el certificado est firmado por el mismo (luego no se puede verificar el CA) y porque el certificado pertenece en teora a otra web, no al host 192.168.2.1. Aun as, si deseamos acceder de todos modos a dicha web, tan solo tendramos que aadir una excepcin, desplegando I Understand The Risks y aadiendo la excepcin:

Esto permite almacenar en nuestro equipo certificados especficos de terceros, marcndolos como seguros. Muchas veces la otra opcin es simplemente aadiendo a nuestra base de datos el certificado del CA, configurndolo para que pueda verificar cualquier certificado que hagamos uso que est firmado por dicho CA. De lo contrario, lo normal es que las comunicaciones sean abortadas si se detecta que el certificado no es vlido para nuestro sistema. La mejor forma de crear certificados es posiblemente gracias a OpenSSL, aunque es una herramienta creada para ser usada por linea de comandos. Tiene la ventaja no obstante de ser altamente configurable. Para los que deseen no obstante realizar la creacin en un entorno de escritorio, la mejor apuesta posiblemente sea usar IIS, el servidor web de Windows que es incluido en la mayora de todas las versiones de Windows, aunque no instalado por defecto. A travs de l es fcil y cmodo la creacin e instalacin de certificados.

PGP/GPG

PGP (Pretty Good Privacy) es un programa/sistema de clave pblica usando el esquemas PKI que vimos en su momento. De echo el repositorio que se vio formaba parte de PGP/GPG. Por ello no hay mucho que decir a cuanto funcionamiento se refiere. Si bien hemos visto una aplicacin directa de los Certificados digitales para SSL/TLS, con PGP/GPG vamos a hacer lo mismo. GPG en contra partida (Gnu Privacy Guard) es una alternativa libre a PGP. Tanto PGP como GPG cumplen con el estndar OpenPGP, lo cual hace a ambos interoperables mutuamente. Pero que sentido tiene PGP/GPG cuando el mundo est rodeado cada vez ms de los certificados digitales administrados por las grandes empresas? El espritu y la filosofa son muy diferentes. Es cierto que la utilidad podra ser exactamente la misma, pero no hay que olvidar que los certificados digitales tal y como los concebimos ahora mismo estn muy comercializados, es decir, no deja de se un negocio. Es cierto que cualquier usuario de forma particular puede crear un certificado digital para encriptar una comunicacin o simplemente sus datos, pero de nuevo olvidamos que OpenPGP se crea en base a la comunidad Online, sin agencias, sin comercio, sin con completa libertad de uso, donde la legitimidad de una clave pblica radica en la confianza que depositan otros en ella. En este apartado no se usar en ningn momento PGP, siempre gnuPGP. Aun tratndose de una aplicacin de lnea de comandos, es bastante descriptiva. Vamos a ver a groso modo como funciona y algununos ejercicios prctico de ello, presuponemos que GPG ya se encuentra instalado en el sistema.

-Creacin de Keys Es evidente que uno de los primeros pasos es crear las keys que se van a necesitar, aunque esto no es necesario si lo que deseamos es usar gpg para realizar un cifrado simtrico, lo cual tambin es completamente posible. La creacin de Keys es un proceso simple y guiado, en rojo los comentarios
C:\Users\Theliel\Desktop>gpg gen-key Por favor seleccione tipo de clave deseado: Se deben de generar dos par, uno para firmar y otro para cifrar (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (slo firmar) (4) RSA (slo firmar) Su eleccin: 1 En mi caso se opta por la opcin 1, RSA para firmar y RSA para cifrar las claves RSA pueden tener entre 1024 y 4096 bits de longitud. De qu tamao quiere la clave? (2048) El tamao de la clave, por defecto 2048 bits El tamao requerido es de 2048 bits Por favor, especifique el perodo de validez de la clave. 0 = la clave nunca caduca <n> = la clave caduca en n das

<n>w = la clave caduca en n semanas <n>m = la clave caduca en n meses <n>y = la clave caduca en n aos Validez de la clave (0)? 0 La clave nunca caduca Es correcto? (s/n) s Es necesario establecer una caducidad, en este caso nunca caduca Necesita un identificador de usuario para identificar su clave. El programa construye el identificador a partir del Nombre Real, Comentario y Direccin de Correo Electrnico de esta forma: Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de> Nuestros datos Nombre y apellidos: Alma Oscura Direccin de correo electrnico: theliel@almaoscura.com Importante si deseamos posteriormente cifrar/firmar correo Comentario: leccin de gpg Est usando el juego de caracteres `CP850. Ha seleccionado este ID de usuario: Alma Oscura (leccin de gpg) <theliel@almaoscura.com> Cambia (N)ombre, (C)omentario, (D)ireccin o (V)ale/(S)alir? V Necesita una frase contrasea para proteger su clave secreta. Aqu nos solicitara la contrasea de paso para proteger la clave privada Es necesario generar muchos bytes aleatorios. Es una buena idea realizar alguna otra tarea (trabajar en otra ventana/consola, mover el ratn, usar la red y los discos) durante la generacin de nmeros primos. Esto da al generador de nmeros aleatorios mayor oportunidad de recoger suficiente entropa. La entropa garantiza una buena clave generada aleatoriamente +++++ +++++++++++++++ gpg: clave F86191C9 marcada como de confianza absoluta claves pblica y secreta creadas y firmadas. Creacin completada de los dos pares de Keys gpg: comprobando base de datos de confianza gpg: 3 dudosa(s) necesarias, 1 completa(s) necesarias, modelo de confianza PGP gpg: nivel: 0 validez: 2 firmada: 0 confianza: 0-, 0q, 0n, 0m, 0f, 2u gpg: siguiente comprobacin de base de datos de confianza el: 2011-02-10 pub 2048R/F86191C9 2010-03-01 Huella de clave = 281E 9FBD AE6A 57FF EC65 D77F 57B5 75E8 F861 91C9 uid Alma Oscura (leccin de gpg) <theliel@almaoscura.com> sub 2048R/342B5359 2010-03-01

Nuestro par de claves queda completamente creado. La clave pblica queda especificada con el ID F86191C9, mientras que la clave pblica para firmar 342B5359. Una vez se ha completado el pequeo asistente, ya dispondremos de todo lo que necesitamos para realizar la tarea que deseemos. Por defecto, las claves creadas son firmadas por nosotros mismos, esto le da a las claves validez completa para nosotros mismos, as como cualquier clave que firmemos.

Despus de la creacin de las claves, lo normal es crear un certificado de revocacin. Un certificado de revocacin lo que nos permite es revocar nuestras clave completamente en caso de que esta haya sido perdida, comprometida y lo que hace es marcar nuestras claves como no vlidas. Dado que se requiere de nuestra propia clave privada para ello, lo normal es crearlo despus de crear nuestras claves, y mantenerlo en lugar seguro. Cualquiera con nuestro certificado de revocacin podra marcar nuestra clave pblica como revocada:
C:\Users\Theliel\Desktop>gpg gen-revoke -o revocar.txt almaos

sec 2048R/F86191C9 2010-03-01 Alma Oscura (leccin de gpg) <theliel@almaoscura.com>

Crear un certificado de revocacin para esta clave? (s/N) s Por favor elija una razn para la revocacin: 0 = No se dio ninguna razn 1 = La clave ha sido comprometida 2 = La clave ha sido reemplazada. 3 = La clave ya no est en uso Q = Cancelar (Probablemente quera seleccionar 1 aqu) Su decisin? 0 Introduzca una descripcin opcional; acbela con una lnea vaca: > Razn para la revocacin: No se dio ninguna razn (No se di descripcin) Es correcto? (s/N) s Necesita una frase contrasea para desbloquear la clave secreta del usuario: Alma Oscura (leccin de gpg) <theliel@almaoscura.com> clave RSA de 2048 bits, ID F86191C9, creada el 2010-03-01 se fuerza salida con armadura ASCII. Certificado de revocacin creado.

Armadura ASCII es el trmino que llama GPG para formatear los datos en BASE64, que como ya dijimos su principal uso es poder interpretar en texto plato archivos binarios. As pues, si abrimos el archivo de texto revocar.txt, lo que veremos ser algo as:
BEGIN PGP PUBLIC Version: GnuPG Comment: A revocation certificate should follow KEY v1.4.10 BLOCK (MingW32)

iQEfBCABAgAJBQJLjPn+Ah0AAAoJEFe1dej4YZHJKC0IAKurWg5Ft9ubYrxyASyL ISEy5hSfVjslpVnT9qjwnMYPHYwCv7YbpHki6hGYowH3lFoYMaFl4QmrmqoIsiuV OkrqekCPuGGt/kZCzkOh96lYYp8KWGfxBbjQyU17/yt9qLPlM0vEYNv6QHGKi/5K flkPE0Y57rtC+Kz6WeCF6e8ao7yqfKJNkbvPLtpYTUzcrFzRiraBwNaIBuyRMod/ fmemqN+QkYf7PgVec0qLe8o5E+OBsHhFnwbYf0jQDmj2ehGpTlwLi2H02Ppfu1Wq w6/DO33haTvFgXw1UwO4sgWACvO9bhGy711CJBFo4zto6jwHLxf/CIDNOJPTuY0S Fcc= =2B98 END PGP PUBLIC KEY BLOCK

Evidentemente esta clave ha sido creada tan solo para estos fines, luego no me importa publicar el certificado de revocacin. Con l, cualquier persona podra revocar dicha key.

-Edicin de Keys Otra accin comn es la edicin de Keys. Esto tiene como objetivo por ejemplo aadir una identidad nueva a nuestras claves, modificar la expiracin, modificar la contrasea de paso es decir administrar nuestras keys. Para ello tan solo se requierer el comando gpg edit-key [CLAVE] donde clave es cualquier identificativo de la Key que deseamos modificar. Por ejemplo podramos poner el ID de nuestra clave, el correo electrnico, el nomre o apelllidos cualquier dato es suficiente:
C:\Users\Theliel\Desktop>gpg edit-key almaos es reconocido por almaoscura.com, que es una key presente Clave secreta disponible. especifica que la key a editar disponemos la clave privada pub 2048R/F86191C9 creado: 2010-03-01 caduca: nunca uso: SC confianza: absoluta validez: absoluta sub 2048R/342B5359 creado: 2010-03-01 caduca: nunca uso: E [ absoluta ] (1). Alma Oscura (leccin de gpg) <theliel@almaoscura.com> Orden> showpref showpref muestra el orden de preferencias de los algoritmos criptogrficos para simtrico se usar AES256, para Hash SHA256, para compresin ZLIB [ absoluta ] (1). Alma Oscura (leccin de gpg) <theliel@almaoscura.com> Cifrado: AES256, AES192, AES, CAST5, 3DES, IDEA Resumen: SHA256, SHA1, SHA384, SHA512, SHA224 Compresin: ZLIB, BZIP2, ZIP, Sin comprimir Caractersticas: MDC, Sevidor de claves no-modificar Orden> almaos

Con help tendremos una lista extensa de todas las posibilidades. Lo ms comn es la gestin de los identificadores, cambio de contrasea de paso..

-Encriptacin/Desencriptacin: Como herramientas criptogrficas, gpg puede usarse perfectamente para cifrar cualquier archivo o contenido con cifrado simtrico o asimtrico. Hacerlo es simple: Cifrado simtrico usando AES256: gpg -c cipher-alg AES256 -o test_cifrado.txt test.txt -c especifica cifrado simtrico, cipher-alg el algoritmo de cifrado simtrico, -o el archivo de salida, test.txt el archivo origen. Nos solicitar una contrasea y nada ms

Cifrado asimtrico usando la key pblica de AlmaOscura: gpg -er almaosc armor -o test_cifrado_a.txt test.txt -er especifica encriptacin para un destino concreto (con lo que tenemos que tener su clave pblica), -armor fuerza la salida en BASE64 Descifrar cualquier contenido: gpg -d -o test_d test_cifrado.txt automticamente la pantalla nos dir como se ha cifrado. Si es cifrado simtrico necesitamos la clave, si es asimetrico tener la clave privada y la contrasea de paso:
C:\Users\Theliel\Desktop>gpg -d -o test_d test_cifrado_a.txt Necesita una frase contrasea para desbloquear la clave secreta del usuario: Alma Oscura (leccin de gpg) <theliel@almaoscura.com> clave RSA de 2048 bits, ID 342B5359, creada el 2010-03-01(ID de clave primaria F86191C9) gpg: cifrado con clave $s de $u bits, ID $s, creada el $s Alma Oscura (leccin de gpg) <theliel@almaoscura.com> C:\Users\Theliel\Desktop>

-Envo o recepcin de Keys a un repositorio Para acabar, otra funcin igualmente importante es poder exportar nuestras claves pblicas para que todos puedan tener acceso a ellas. Una vez realizado, nuestras keys sern enviadas a uns ervidor pblico, y de este a otras rplicas a lo largo de todo el mundo, para aque as pueda cualquier persona del mundo poder enviarnos un mensaje cifrado o firmado hacia nosotros: gpg keyserver gpg.mit.edu send-key theliel@almaoscura.com Del mismo modo, si se especifica recv-key en vez de enviar al servidor la key especificada, se obtiene de l la clave pblica especificada, necesaria si deseamos cifrar un mensaje para dicha persona o enviar un correo seguro o Aunque existen muchas ms posibilidades para GPG, enumerarlas una tras otra todas las opciones sera realmente poco prctico, dado que para ello est el manual de usuario de GPG, y aqu no pretendemos crear un manual de uso de GPG, sino comprender como funciona GPG y como poderlo usar, sobre todo en el siguiente punto, Correo electrnico

Correo Electrnico Si TLS/SSL es la aplicacin prctica predominante al uso de certificados digitales o firmas, el correo electrnico sera la segunda aplicacin prctica ms usada. La idea de cifrar y/o firmar el correo es lo ms lgico. En todo momento hemos estado hablando de A enva un

mensaje a B. En realidad el correo electrnico es esto a groso modo. Luego no es extrao que existan funciones ms que extendidas para poder realizar este tipo de prcticas. Cuando hablamos de TLS/SSL dijimos que muchos proveedores de correo electrnico usan estos protocolos para evitar que un tercero pueda leer el correo. Esto es cierto, pero esto no significa que el correo en s est cifrado. Por ejemplo, si envo un correo sin cifrar por medio de gmail que usa para SMTP TLS, el correo se enva de forma cifrada desde el origen (mi ordenador) hasta el destino (el servidor de Gmail). Cualquier usuario que acceda al correo podr leerlo. SSL/TLS no garantiza de modo alguno que el mensaje sea ledo nicamente por el destinatario concreto, simplemente que el envo (o recepcin en caso de IMAP o POP) se realiza de forma encriptada. A da de hoy existe un estndar mayoritario, soportado por prcticamente todos los gestores de correo electrnico llamado S/MIME. S/MIME nos permite poder cifrar o firmar mensajes de correo electrnico si disponemos de un certificado para ello. Recordemos que no todos los certificados valen para todo, tendremos que tener un certificado que nos permita firmar y/o cifrar correo. En el caso concreto del DNI-e, nos permite por ejemplo tan solo firmar, dado que nuestro DNI-e no se le asocia ningn correo electrnico. En caso de los certificados CERES si que se le aade la opcin de firmar o cifrar. Para poder firmar un correo no se requiere nada en realidad, tan solo disponer de un certificado que permita la firma de correo y la clave privada de l evidentemente. En cambio para poder cifrar un mensaje lo que se requiere es la clave pblica del destinatario, con lo que se depende de que este tenga o no tenga un certificado y que sea vlido. Es una pena no obstante que el DNI-e expedido en espaa no tenga la opcin a la hora de expedirlo de asociarlo a un correo electrnico. Supongo que es solo cuestin de tiempo que esto se permita. Del mismo modo que podemos usar S/MIME para firmar o cifrar mensajes por medio de certificados, dependiendo de la versin que tengamos de GPG podremos hacer lo mismo o necesitaremos tener instalado en nuestro gestor de correo alguna aplicacin (addon) para hacerlo, es el caso de EnigMail para Thunderbird. Su funcionalidad es prcticamente la misma a la de S/MIME, lo que sucede es que en este caso no se trabajar con certificados, sino con el administrador de claves de GPG. Vamos a ver algunos ejemplos de cifrado y firma a travs de S/MIMI y a travs de EnigMail. No hay que decir que es posible tan solo firmar, firmar y encriptar o tan solo encriptar.

-S/MIME Usando Thunderbird, es muy fcil configurarlo para que por defecto se firme todos los correos redactados por una cuenta concreta. Tan solo es necesario especificar el certificado que ser usado por dicha cuenta:

Una vez se han especificado los certificados a usar, tan solo es necesario redactar el correo deseado y en S/MIME seleccionar firmar. El mensaje se enviar sin problema alguno. La firma no deja de ser un archivo adjunto. Dependiendo de como sea abierto el correo, este nos verificar o no la firma adjunta. Por ejemplo, si el correo se abre con gmail, este tan solo ver que existe un archivo adjunto, si se abre con Thunderbird, directamente intentar verificar la firma del origen, con lo que el equipo deber de tener los certificados pertinentes. Si es un mensaje tan solo firmado, la extensin ser P7S, y P7M si el mensaje est cifrado o cifrado y firmado, siendo el adjunto en este caso el cuerpo del mensaje o cualquier adjunto que tambin contenga. Si vemos el mensaje desde el punto de vista de gmail, tendremos algo as:

En cambio, de cara a un gestor de correo, lo que tendramos sera algo as (No es el mismo correo):

En este caso, se puede ver en la esquina superior izquierda dos iconos. El primero significa que existe una firma, pero no se ha podido verificar. El segundo que el mensaje est cifrado. En pantalla, el texto probando probando es mostrado automticamente ya desencriptado. Por qu existe un error en la firma en este caso? Porque fue firmado por un remitente (correo electrnico) que no coincide con el correo electrnico especificado en el mismo certificado. Esto sucede si por ejemplo firmamos un correo enviado por otra cuenta con el certificado que poseemos pero que en dicho certificado lo creamos para otro correo. En cambio, el cifrado es vlido, dado que para cifrar tan solo se requiere el certificado, la clave pblica del destinatario, claro que tan solo el destinatario, que posee la clave privada, puede desencriptarlo. Las claves privadas de los certificados almacenados en el propio sistema no suelen estar protegidas por una clave de paso, en cambio los certificados almacenados en una Smart Card como el propio DNI-e suelen estar protegidos por un PIN que es necesario introducir correctamente para tener acceso a nuestra clave privada.

Debera ser posible desencriptar cualquier archivo p7m directamente con OpenSSL especificando la key: openssl smime -decrypt -in smime.p7m -recip my.pem Siendo my.pem el certificado con la clave privada exportado y smime.p7m el mensaje cifrado/firmado

-GPG El procedimiento en realidad es exactamente igual que el visto para S/MIME. Lo primero es asociar nuestras claves a la cuenta que desamos, al igual que se hizo para asociar a una cuenta los certificados correspondientes:

Y la recepcin o envo de este tipo de correos es exactamente igual que con un certificado. Al firmar el correo lo normal ser introducir la clave de paso para desproteger la clave privada y con ella poder realizar la firma:

A diferencia de S/MIME, PGP/MIME no cifra los mensajes o los firma adjuntando al correo el mensaje cifrado, sino que directamente suele cifrar el mensaje. Si nuestro gestor

de correos reconoce que est firmado y/o cifrado por OpenPGP, nos mostrar el mensaje o nos dar un error de apertura, no obstante si no reconoce el formato o es abierto desde cualquier gestor online, lo normal es encontrar como es ya costumbre el mensaje y/o contenido en BASE64. Para el mensaja enterior sera:
BEGIN Version: GnuPG v1.4.10 (MingW32) hQIMA0n/ fXfs2GxwARAAyJCLgdeCtg8f53jwWPSc+MZuJ15Kw/9dUEacIP79+WZl xY8YdFf6pgkwL1Xov9P1k9vlwMN7uwYLa/g5TjUxqatoURxO+tHO6kVzFIGWn9W8 1KB/dxJWib4u98ACV0CIVC0waYyhB2XiHmrZR/TZYqEvwHHJx1l4I6t2Z2QPaahm vdiTxOUwDixQI26qoNoUYRUei6yovKiJbviV0Sr6oItjU5XVxOVcyrpcGwTuOT34 kWig+u+CFv5rC6my2BtX1C/Aq/LC0YvIjTBce8fFNL84B5V71dgEmJhCNXSlAm23 pJ8zfltVq+ZVXV2koCKLvEoPytpyy+u/RiIUS30J/hrW1OdAdX3RVDh54h/7ODZu z2YFjxbWQdiTWsENgpVVZ4KiA6irSz6Hc+fpJZMlUCHDG6UgSkY4Qx53c0Aj7paz dxE/aQbGxxuZkqsKFOo6UhNfhN9aj2a5+IN5uI3vcKWlwBGQ1iCXgn4CVN6vUf5S Kd9NV2sutZTxgOhN58xekYSLY459RPuZSHCQz42TWuku9UVhTiclg98RzSti1auY 9v+NJZtgJn5Ug9odJv7yJ4Opa0kqpFH3bbgO2dloflgpZMDnSzvbouxxl79ecjV7 IoxL8Vml4+2W3WTWw81Qh4/p9ShFOXdUhsAQxd3Q+W4ub84yrVBdcPZZLQ/R/VPS wQ4B3yCR6PyfWR8U3ovO6TUHvPXQQdO32EInaXu4HJJkNdGf4phTk3/r8ichctbN t2/yM4GkaVLamxSAWe5gOXfc+OtWap8W/fIsqzChrKmiQwcvO7B4ZCeEZrJ3Fjnq 8Nfr97vFFjDCdGA0gjcUyZiLUrfoljEETTxGQ5/dWYXyw5lo/yhBH+CQaG+woSDl 7BNERdn8TtTxX3BUMx40eIJgbW/nkefj7+ZRiclJ1ecmpkWuNSjWcj7USEMB4yUI ZjNeJH0hqsbCezyaYBfArtgZ2XAeW9juNOUcdt+dHkWVZtcb6BqgbABzZ1Y4oFXV GOqZcp0tXPrDCUNuupEDiTdnJOQvF7gaOr5q7o2Brznmzs4inh6xvjEuhMoSjmui yh41jAKMkpb2L3abUbaPgHWCMCWO0GjEtXkDlXVebT37X0W1cK9g4yQTT8Slkuop UQmQFD+8CI35wXDQJqjZ9/Oj5x2iDYiL2czkOiYvOxbuB9+hoDFqMSYQeQkOFzLn MkmDL7PBoN5zDLzlpJj1SbZxN7GmcLxO+RSmmCnHxZdHfzkeuP5VSUsNkHBJs7iH P4ZK002DLRoJw0OygcTdWkfuq7dcUkT8JHbpUtDLV7A= =wSZC END PGP MESSAGE PGP MESSAGE

En realidad, ese mismo texto podra ser procesado directamente por GPG por linea de comandos para desencriptar y verificar la firma. Si copiamos dicho texto a un documento txt por ejemplo y procesamos gpg de la siguiente forma:
C:\Users\Theliel\Desktop>gpg -d 1.txt Necesita una frase contrasea para desbloquear la clave secreta del usuario: Pepito Grillo <theliel@almaoscura.com> clave RSA de 4096 bits, ID XXXXXXXX, creada el 2008-07-16(ID de clave primaria XXXXXXX) gpg: cifrado con clave $s de $u bits, ID $s, creada el $s Pepito Grillo <theliel@almaoscura.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

prueba gpg: Firmado el 03/02/10 15:10:00 usando clave RSA ID XXXXXXXX gpg: Firma correcta de Pepito Grillo <theliel@almaoscura.com> gpg: alias Pepito Grillo <theliel@almaoscura.com>

Y efectivamente, Prueba era el texto del mensaje. Del mismo modo, al desencriptar el mensaje, se puede verificar que este estaba tambin firmado, y que la firma es vlida. Esto quiere decir que el uso de PGP/MIME en realidad no es ms que una interfaz sencilla para poder encriptar y cifrar el contenido que sea necesario.

Gracias tanto a PGP/MIME o S/MIME es simple y eficaz poder firmar o enviar archivos cifrados. Aunque es cierto que no es una prctica muy comn el hacerlo, s que es una prctica completamente recomendada si se desea evitar el eMail Spoofing o ataques para interceptar el contenido de los correos. En el tema de Sniffing, veremos la importancia de esto, tanto de usar TLS/SSL como el cifrado o firma de mensajes. Lo que puede parecer desde un punto de vista domstico algo sin importancia, si que la tiene si los usuarios supiesen en realidad los peligros que entraa Internet simplemente por el desconocimiento de las propias tecnologas.

Firmas Para acabar con las aplicaciones prcticas (aunque no son ni mucho menos las nicas), vamos a hablar del firmado de aplicaciones. En realidad, no es ms que una extensin a la firma que ya hemos visto en los correos electrnicos o las firmas usadas por GPG para archivos. Lo cierto es que cada vez ms programas permiten la firma de los documentos. Con la llegada del DNI-e, del cual hablaremos un poco al final de este captulo, muchos trmites burocrticos son posibles hacerlo simplemente con el DNI-e. Esto es debido a la posibilidad que tenemos de firmar documentos ya no solo con nuestra firma manuscrita, sino tambin a los certificados digitales de firma que nuestro DNI-e posee. Con el tiempo, veremos cada vez ms programas que permiten el firmado de documentos. El correo electrnico tan solo es una de esas aplicaciones, pero no la nica. Vamos a ver por ejemplo lo sencillo que podra ser dar validez legal a un documento Word o PDF. Y digo validez legal porque si realizamos una firma con nuestro DNI-e, es igual como hemos dicho como si firmamos con nuestra firma manuscrita cualquier documento. Recordar el trmino de No Repudio. Para documentos PDF tan solo se debe acudir a la funcin Firmar y selccionar el tipo de firma, si queremos que sea incrustrada o simplemente certificar el documento. En Office, esto se hace de forma anloga a travs del men: Colocar Firma. En un caso o en el otro,

en el momento que se accede al formulario de firma se nos mostrar la lista de certificados disponibles para ello, si tenemos el DNI-E en su lector podremos acceder a nusetros certificados de l. En caso de ser un certificado instalado en el sistema podremos seleccionarlo igualmente:

En el desplegable tan solo tendremos que seleccionar el certificado que deseamos utilizar, en este caso he optado por el certificado de Firma de mi DNI-e. Por seguridad, el software del DNI-e pide una segunda confirmacin cada vez que el certificado de firma va a utilizarse, especificando la peligrosidad de ello. Peligrosidad que es exactamente la misma que puede tener nuestra firma en un papel. Nadie firmara un papel sin leerlo. Esto es exactamente igual. En Acrobat, al terminar el proceso se colocar de forma visible (o no) nuestra firma, exactamente igual que en Word o en la mayora de los programas que permitan realizar firmas.

DNI Electrnico Para acabar vamos a dedicarle algunas palabras al DNI-e, expedido aqu en esta Espaa nuestra, que empez hace ya unos aos a imponerse. Se ha hablado mucho del DNI-e y de todas las supuestas maravillas que es posible hacer con l. Del mismo modo no han sido pocos los que lo han criticado. Qu hay de verdad en todo ello? El DNI-e es una iniciativa pionera y hay que verla como tal. Ello implica que no podemos esperar que todas las maravillas que promete puedan ser visibles en el poco tiempo que lleva en funcionamiento. Si bien es cierto que el sistema de funcionamiento del DNI-e no es ms que un par de certificados para validar nuestra identidad, no es facil de un da a otro tener toda la infraestructura necesaria para que estos certificados sean realmente tiles de cara a la burocracia. La idea principal del DNI-e es sin duda el poder realizar cualquier trmite con la administracin de forma remota. A fin de cuenta la necesidad de personalizacin fsica en una entidad o administracin es para garantizar la identidad de dicha persona. En cambio, lo cierto es que para el 99% de todos los trmites no sera necesario movernos de la pantalla de nuestro ordenador si existiese una forma que garantice nuestra identidad. Y ese es el Alma del DNI-e. Es por ello por el que se incluyen dos certificados, uno para autentificacin y otro para firma, que son los dos tipos de certificados que podramos necesitar a la hora de hacer cualquier gestin a travs de internet. El problema es que las instituciones, administraciones y otros tienen que adaptarse a este nuevo modelo. A esto surge otro problema, que cada cual usa el sistema que ms le place. Esto se refleja en problema con los navegadores a fin de cuentas. Todos estas gestiones son posibles gracias a conexiones TLS mutuamente autentificadas y, en caso de ser necesario, la firma de algn documento del que se requiera validez legal. Luego un peso importante recae en los navegadores, en los protocolos TLS/HTTPS en como esas comunicaciones son realizadas. Al no existir un consenso de como realizar las comprobaciones, de si es mejor usar JAVA o si es mejor usar PHP, o si es mejor usar provoca lo que son las mayores quejas de todo el sistema: Me funciona con IE, pero no con Firefox Me funciona con Firefox, pero no con IE, A la tercera que intento funciona, pero las otras dos veces nada. Esto son errores comunes para cualquiera que haya intentado realizar trmites por el DNI-e. No obstante, con el paso de los das, cada vez son ms las instituciones que quedan recogidas para hacer uso del DNI-e. Es solo cuestin de tiempo que prcticamente todas las gestiones burocrticas sean posible realizarlas sin movernos del asiento, simplemente identificndonos ante la administracin con nuestros certificados. Actualmente es posible realizar gestiones como el acceso a la banca electrnica, permiso por puntos, matrculas de la universidad, certificaciones estatales, becas, oposiciones, SAS, vida laboral

El DNI-e no es ms que una Smart Card de las que hemos estado hablando, una tarjeta de plstico con un microprocesador criptogrfico, similar en parte a lo dijimos quera un

mdulo TPM. Dicho procesador criptogrfico posee funciones para generar nmeros aleatorios, generar claves RSA por s mismo, generar Hash, almacenar certificados, realizar cifrado Triple DES las especificaciones completas pueden encontrarse en la web del DNI-e, tan solo hay que conocer que dicho procesador criptogrfico es un ST19wl34 Bsicamente es una tarjeta de memoria que costa de tres zonas independientes: 6KB RAM, 224KB ROM, 34KB FLASH. Lo que sucede que cada una de dichas zonas de memoria est protegida por un Firewall interno con reglas de acceso a cada una de ellas, y adems cada zona de memoria puede particionarse. Es decir, se pueden crear reglas en el firewall interno de modo que tan solo ante ciertas operaciones y ciertas validaciones, se permita el acceso a ciertas particiones de la zona de memoria que sea. De las tres zonas de memoria podemos inferior que en los 224KB destinados a la ROM se encuentra el sistema operativo del DNIe, llamado amigablemente DNIe v1.1. En los 34KB de la memoria flash se encontraran los datos de nuestra propia tarjeta, es decir nombre, apellidos, dni, certificados, claves y evidentemente la memoria RAM para las operaciones en activa que pueda necesitar. Evidentemente la memoria flash est particionada en diferentes regiones de seguridad. Tan solo podemos hacer una idea de como es ello en relacin a los datos aportados por la propia administracin: ZONA PBLICA: Accesible en lectura sin restricciones, contenido:

Certificado CA intermedia emisora. Claves Diffie-Hellman. Certificado x509 de componente.

ZONA PRIVADA: Accesible en lectura por el ciudadano, mediante la utilizacin de la Clave Personal de Acceso o PIN, conteniendo:

Certificado de Firma (No Repudio). Certificado de Autenticacin (Digital Signature).

ZONA DE SEGURIDAD: Accesible en lectura por el ciudadano, en los Puntos de Actualizacin del DNIe.

Datos de filiacin del ciudadano (los mismos que estn en el soporte fsico). Imagen de la fotografa. Imagen de la firma manuscrita.

DATOS CRIPTOGRFICOS: Claves de ciudadano

Clave RSA pblica de autenticacin (Digital Signature). Clave RSA pblica de no repudio(ContentCommitment). Clave RSA privada de autenticacin (Digital Signature). Clave RSA privada de firma (ContentCommitment). Patrn de impresin dactilar.

Clave Pblica de root CA para certificados card-verificables. Claves Diffie-Hellman.

DATOS DE GESTIN:

Traza de fabricacin. Nmero de serie del soporte.

De estos datos podemos imaginar que la flash est dividida en cuatro partes. Una de ella de acceso no restringido, donde se encontraran el Certificado de la CA intermedia (no el certificado CA raiz), que sera en este caso AC DNIE 003, el certificado raiz CA recae sobre AC RAIZ DNIE. En la misma zona se encontraran las claves DH. DH es un algoritmo usado para comenzar a intercambiar claves. Por ltimo se encuentra el certificado x509 de componentes, que se refiere a algunos de nuestros datos, como lo es Nombre y apellidos, DNI o equipo de expedicin. La segunda zona de la memoria es usada para almacenar los dos certificados que posee, el certificado de firma y el de autentificacin, que aunque los dos pueden ser usados para firmar, tan solo el de firma tiene habilitada la funcin de No repudio, la cual ya hemos hablado de ella, lo cual hace que una firma digital con l tenga el mismo valor que un documento firmado manuscrito. En la zona de seguridad tan solo se encontraran los datos expuestos, los datos de la persona fsica, imagen de la fotografa, la firma. Quedara por pensar donde se encuentran alojados los datos criptogrficos. Por su seguridad, podramos pensar que se encontraran en una zona especial del mismo procesador criptogrfico, pero esto no es as. Luego podemos pensar que se encuentran en una zona de memoria Flash, la cual tiene unas reglas de acceso muy limitadas. Por ejemplo, una zona de memoria marcada tan solo para lectura interna. Es decir, los datos almacenados en ella tan solo pueden ser ledo por el mismo OS de la propia Smart Card, sin que existe posiblidad de lectura desde el exterior. Si nos damos cuenta, las tres zonas de memoria anteriormente especificadas pueden ser extradas o modificadas desde el exterior. En cambio, estas zonas de memoria no. Tan solo existir seguramente un protocolo configurado en el propios OS del DNIe para generar, borrar, crear, eliminar nuevas claves, pero nunca para extraerlas.En esta zona especial se encontrara la informacin ms sensible, comenzando por las claves privadas de los propios certificados. El resto del hardware del DNI-e son algunos mdulos aceleradores para las operaciones criptogrficas y una memoria ROM que incluyen libreras y software ya creado por ST para ser usado por el OS introducido en la ROM de usuario. Posee a parte algn generador de nmeros aleatorios y el resto es prcticamente electrnica pura y dura. Visto as, es ms fcil comprender que es en realidad el chip de nuestro DNIe, que no es algo tan raro o tan complicado de comprender. Por supuesto, esto tan solo es todo especulativo, dado que tan solo podemos imaginar en funcin de los datos que han sido publicados. Quizs sera posible desgranar un poco ms el DNIe y ver realmente como est

diseado, los comandos APDU de acceso pero requerira paciencia y tiempo, y tampoco este captulo trata sobre ello, tan solo un repaso general de lo que es el DNIe y de como funciona.

Para terminar todo este captulo, recordar que la tecnologa est para usarse. Un sistema usado responsablemente y sabiendo de que se trata, otorga un ndice de seguridad muy muy alto. No implica que tengamos que ser neurticos en cuanto a seguridad se refiere, pero como veremos en otros temas como el Sniffing, Spoofing nunca puedes fiarte de quien pueda estar al otro lado, y mucho menos de las intenciones que puede tener. A quien esto le parezca desmesurado, que se comience a preguntar por qu hay tantos problemas de seguridad a da de hoy.