martes, 20 de junio de 2017

Jornada: La LOPD en los centros públicos de Formación profesional

Ayer, 19 de junio de 2017, tuve la oportunidad de participar, como asociado de PRIBATUA (Asociación Vasca de Privacidad y Seguridad de la Información / Pribatutasun eta Informazio Segurtasuneko Euskal Elkartea), en la Jornada: "La LOPD en los centros públicos de formación profesional" organizada por Ikaslan Bizkaia, y que tuvo lugar en el CIFP Bidebieta LHII de Basauri.
Una jornada muy interesante y en la que durante mi ponencia traté de reflexionar con los profesionales involucrados: Directores de Centros, Docentes,..., sobre su problemática en materia de protección de datos de carácter personal, respecto tanto a la normativa actualmente de aplicación (LOPD y RDLOPD) como a las principales novedades de aquella que será de aplicación a partir del 25 de mayo de 2018 (nuevo reglamento europeo de protección de datos, RGPD).
La verdad es que me quedé muy gratamente sorprendido con la participación activa de los asistentes, tanto durante la ponencia como en el turno de preguntas, dudas y comentarios. Algunas de la preguntas realizadas:
Como tras cada ponencia en la que tengo el privilegio de participar, sinceramente, no sé si conseguí transmitir de forma adecuada y comprensible aquello que pretendía comunicar, ni mucho menos resolver algunas de las dudas que se plantearon en este caso específico, pero de lo que sí estoy seguro es de que yo aprendí un montón.

Eskerrik asko Ikaslan Bizkaia por habernos invitado a participar.

jueves, 11 de mayo de 2017

Criptografía (LIII): ataque a RSA mediante factorización (IV)

En esta ocasión me referiré al método de factorización de Dixon, un algoritmo de propósito general.

Recordar que, tal y como comenté en un post anterior, mientras que en los algoritmos de propósito específico (Fermat, rho Pollard, p -1 Pollard,...) el tiempo de ejecución depende de las características propias de los dos factores primos (p y q) del módulo (n) a factorizar, en los de propósito general éste sólo depende del tamaño del módulo.

Antes que nada explico lo que he entendido sobre este método (espero no equivocarme mucho) y pongo un ejemplo con el número que vengo utilizando como módulo en los ejemplos de cifrado RSA.

Si no lo he entendido mal, la idea básica de este método es, dado un número n a factorizar, encontrar dos números x e y tales que x2 º y2 mod n, con lo que (x - y) (x + y) es un múltiplo de n, y, por consiguiente, tanto el mcd(x - y, n) como el mcd(x + y, n) nos entregarán un factor no trivial de n (distinto de 1 y n) siempre y cuando ni (xy) ni (x + y) sean múltiplos de n.

Supongamos que queremos factorizar n, el método consiste en:

a) Tomar una base (B) de números primos consecutivos, empezando en 2, unión con -1, es decir, B = {-1, p1p2p3,...}.

b) Después elegimos números enteros zi tales que zi2 pueda factorizarse como el producto de potencias de elementos de la base (Bmod n, de tal forma que: zi2 º (-1)e1 x (p1)e2 x (p2)e3 x (p3)e4 x ... mod n.

c) Cuando encontremos varios números que satisfagan la condición anterior (wj) buscamos un subconjunto de ellos en los que la suma de exponentes de cada elemento de la base (sk) sea par, y eso nos llevará a la congruencia buscada: (w1 x w2 ...)2 º ((-1)s1/2 x (p1)s2/2 x (p2)s3/2 x (p3)s4/2 x ...)2 mod n.

Es decir:
x2 º y2 mod n.

d) Con lo que tanto el mcd(x - yn) como el mcd(x + yn) es muy probable que nos entreguen un factor no trivial de n (distinto de 1 y n).

Ejemplo: sea n = 52.841.

a) Tomamos como Base: B{-1, 2, 3, 5}.

b) Elegimos como números enteros cuyos cuadrados se factorizan como el producto de potencias de elementos de la base módulo n, los siguientes:

(229)2 º (-1)1 x (2)4 x (3)0 x (5)mod 52.841
(514)2 º (-1)1 x (2)0 x (3)2 x (5)0 mod 52.841

c) (229 x 514)2 º (22 x 3 x 5)2 mod 52.841

Lo que nos da: (12.024)2 º (60)2 mod 52.841

d) mcd(12.024 - 60, 52.841) = 997, y , por tanto, hemos conseguido factorizar el módulo: 52.841 = 997 x 53.

Pero en la práctica: ¿cómo se implementa este método?. En un próximo post intentaré poner un algoritmo para ello, conforme a lo que he entendido, y aplicarlo a este mismo ejemplo. ¿Algún voluntario para incluirlo en forma de comentario?.

miércoles, 26 de abril de 2017

Criptografía (LII): ataque de intermediario a RSA

En anteriores posts de este blog he tratado sobre diferentes ataques teóricamente posibles al cifrado RSA, pero que tal y como decía, al menos actualmente, son ineficientes con la potencia de cálculo de los ordenadores actuales. Sin embargo hay otros ataques posibles y que pueden tener más probabilidades de éxito.

Tal y como también he dicho en anteriores posts de esta serie sobre criptografía:

"El eslabón más débil de la cadena de seguridad (y la criptografía no es una excepción) lo constituimos las personas".

Es decir, podemos tener un criptosistema muy robusto (muy seguro conceptualmente), como es el caso de RSA, pero si las personas que lo administramos y/o utilizamos no hacemos un uso adecuado del mismo éste podría ser "roto" con relativa facilidad.

En este post, como ejemplo de ésto, me voy a referir al ataque de intermediario (MitM, por las siglas en inglés de: "Man-in-the-Middle"), que, aunque en el título de este post lo he indicado como ataque al cifrado RSA, realmente puede emplearse para atacar cualquier criptosistema de clave pública.

En este tipo de ataques el atacante no se hace con la clave privada de los usuarios que intercambian entre sí mensajes cifrados, pero está en disposición de leerlos (descifrarlos y obtener así el texto en claro) e incluso de modificarlos, sin que emisor ni destinatario se den cuenta de ello.

Supongamos que un atacante (C) tiene acceso al directorio donde se encuentran las claves públicas de dos usuarios (A y B), entonces podría almacenar ambas claves y sustituirlas por otras dos previamente generadas por él y, por tanto, de las que dispone de sus respectivas claves privadas, o bien, si el intercambio de claves públicas entre A y  B se produce mediante sendas comunicaciones por un canal no seguro y C es capaz de interceptarlas, entonces C podría enviar a cada uno de ellos una clave pública generada por él haciéndoles creer a ambos que la clave pública que reciben es la correspondiente a la otra parte.
De esta forma, B cree disponer de la clave pública de A (KA), cuando realmente es una clave pública de C (KC1), y lo mismo le ocurre a A, que no dispone de la clave pública de B(KB) sino de otra clave pública generada por C (KC2), estando este último en disposición de leer los mensajes cifrados que se intercambien A y B, e incluso, como ya he dicho, de modificarlos. Todo ello sin que ni A ni B se den cuenta de que sus comunicaciones están comprometidas.

Veamos cómo. Supongamos que A quiere mandar un mensaje cifrado a B, para lo que utilizaría la clave pública que cree que es de B pero que realmente es de C (KC2) y se lo enviaría a B. C intercepta el mensaje y lo descifra con la clave privada correspondiente a la clave pública con la que A lo cifró (K'C2) y obtiene el texto en claro, rompiendo así el secreto que se pretendía guardar. Después C puede o no alterar el mensaje, cifrarlo con la verdadera clave pública de B (KB) y enviárselo a B como si el emisor fuera A. B descifra el mensaje con su clave privada (K'B) y cree que nadie ha tenido acceso al mismo.

Este ataque funciona de igual forma en sentido contrario (mensaje de B a A) pero el atacante utilizaría para descifrar el mensaje la clave privada K'C1 y después lo volvería a cifrar con la verdadera clave pública de A (KA) y se lo enviaría a éste como si el emisor fuera B.

El ataque de intermediario, si no se toman medidas adecuadas para evitarlo, es posiblemente el más efectivo para "romper" un cifrado RSA y, como ya he dicho antes, cualquier otro criptosistema de clave pública.

Evidentemente, el problema en este caso consiste en que el emisor debe asegurarse de que la clave pública con la que va a cifrar los mensajes es realmente del destinatario al que van dirigidos y no de un atacante. Una forma de hacer esto consiste en la participación de una Autoridad de Certificación (CA por sus siglas en inglés) que a la hora de entregar la clave pública de un usuario (destinatario) a otro (emisor) garantice que ésta es realmente del primero.

martes, 7 de marzo de 2017

'Habemus' Troll

¡Ya era hora!.

Tras exactamente 2.434 días de que naciera este modesto blog, con 352 entradas y 370 comentarios hasta el momento, al fin y como cualquier blog que se precie,

¡Ya tenemos nuestro propio Troll!.

Pero, antes que nada, veamo la definición de Troll en la wikipedia:

"Un troll o trol es un vocablo de Internet que describe a una persona que sólo busca provocar intencionadamente a los usuarios o lectores, creando controversia, provocar reacciones predecibles, especialmente por parte de usuarios novatos, con fines diversos, desde el simple divertimento hasta interrumpir o desviar los temas de las discusiones, también trollean páginas de wikipedia o bien provocar flamewars, enfadando a sus participantes y enfrentándolos entre sí. El troll puede ser más o menos sofisticado, desde mensajes groseros, ofensivos o fuera de tema, sutiles provocaciones o mentiras difíciles de detectar, con la intención en cualquier caso de confundir o provocar la reacción de los demás".

Aunque el origen etimológico de este término parece que nada tiene que ver con "El Señor de los anillos", tal y como nos aclara también la wikipedia: su origen más probable es el de «morder el anzuelo» o «morder el anzuelo mucho más» (troll es un tipo de pesca en inglés), permítaseme la licencia de las imágenes que ilustran este post, ya que soy un fan de Tolkien y porque creo que estos seres encajarían mejor como origen etimológico de este término.

Pues bien, como decía, ya nos empezábamos a preocupar ("¡menuda mierda de blog que tenemos, no comenta ni un solo Troll!"), pero esto se acabó: ¡Ya tenemos nuestro propio Troll!. He borrado sus comentarios y no voy a reproducirlos porque, como todos sabemos, hay que tener mucho cuidado a la hora de alimentarles, es más, no se les debe dar de comer nunca porque mutan a subespecies que dan mucho más la tabarra.

Pero veamos, en concreto, a qué subespecie pertenece este Troll. Para ello fijémonos en varias de las características definitorias que nos pueden dar pistas para su catalogación: se ampara en el anonimato, sólo sabe poner groserías y carece de educación. Basándome en estas apreciaciones objetivas, yo diría que se trata de un Troll "tontolano" (bueno, ya sé que no es muy académico, pero es que no me encajaba exactamente en ninguna de las subespecies descritas hasta la fecha). En definitiva, creo que estamos ante una nueva subespecie aún sin catalogar y a la que me permito bautizar.  

Por favor, querido Troll (tú y yo sabemos quién eres), apúntate el número 1 para que cuando vuelvas a comentar en este blog te identifiques como Troll#1, así todos sabremos que eres tú otra vez, para no equivocarte con otros miembros de tu misma especie que nos visiten, ya que para nosotros tú siempre serás nuestro Troll.

En la medida que vayan visitándonos otros especímenes que pululan por Internet iremos escribiendo nuevos posts de bienvenida, catalogándoles y distinguiéndoles con el número correspondiente.

lunes, 6 de marzo de 2017

Criptografía (LI): el algoritmo DES (III)

En el post anterior puse un ejemplo de cifrado utilizando el algoritmo DES y decía que en éste, para ver si lo he comprendido y he hecho correctamente, voy a descifrar el criptograma que obtuve.

De forma análoga que en el cifrado, como paso previo al descifrado debemos obtener, a partir de la clave (K), de 64 bits, las 16 subclaves (Ki), de 48 bits cada una, que se emplearán en las 16 rondas de la red de Feistel de las que consta este algoritmo, una subclave por ronda.

Ya expliqué en un post anterior como hacerlo, siendo la clave de nuestro ejemplo y las subclaves calculadas a partir de ésta las siguientes:
Y ya estamos en disposición de descifrar el criptograma, para lo que hay que recordar que en este post decía que basta con aplicar las sucbclaves (Ki) en orden inverso que en el cifrado. En nuestro ejemplo el criptograma obtenido es el siguiente:

- En binario:

C = 1001101111111011111110111111010011010000111110010001011000000100

- En hexadecimal:

C = 9BFBFBF4D0F91604


1.- Permutación inicial (IP) de los bits del bloque del criptograma a descifrar:
2.- Red de Feistel de 16 rondas (aplicando las subclaves en el orden inverso al cifrado):

2.1.- Primera iteración:
2.2.- Segunda iteración:
2.3.- Tercera iteración:
2.4.- Cuarta iteración:
2.5.- Quinta iteración:
2.6.- Sexta iteración:
2.7.- Séptima iteración:
2.8.- Octava iteración:
2.9.- Novena iteración:
2.10.- Décima iteración:
2.11.- Undécima iteración:
2.12.- Duodécima iteración:
2.13.- Decimotercera iteración:
2.14.- Decimocuarta iteración:
2.15.- Decimoquinta iteración:
2.16.- Decimosexta iteración:
3.- Permutación final (IP-1) de los bits de la concatenación R16 || L16:
Con lo que el texto en claro (M) sería:

- En binario:

M = 0100010101001010010001010100110101010000010011000100111101001101

- En hexadecimal:

M = 454A454D504C4F4D

Como se observa, he obtenido el mismo texto en claro (M) que en el post anterior, por lo que concluyo que tanto el cifrado como el descifrado son correctos.

jueves, 2 de marzo de 2017

Criptografía (L): el algoritmo DES (II)

En el post anterior decía que iba a completar el ejemplo que puse de cifrado utilizando el algoritmo DES. Lo intento, pero bien entendido que sólo concluiré que es correcto, más o menos, cuando en el siguiente post consiga descifrar el criptograma (C) que obtengo en éste. Si no lo consigo algo habré hecho mal y corregiré este post y el anterior.

Como paso previo al cifrado debemos obtener, a partir de la clave (K), de 64 bits, las 16 subclaves (Ki), de 48 bits cada una, que se emplearán en las 16 rondas de la red de Feistel de las que consta este algoritmo, una subclave por ronda.

Ya expliqué en el post anterior como hacerlo, siendo la clave de nuestro ejemplo y las subclaves calculadas a partir de ésta las siguientes:
Y ya estamos en disposición de cifrar un texto en claro, para lo que hay que recordar que este algoritmo se aplica sobre bloques de 64 bits del mismo. En nuestro ejemplo proponía cifrar el siguiente bloque:

- En binario:

M = 0100010101001010010001010100110101010000010011000100111101001101

- En hexadecimal:

M = 454A454D504C4F4D

1.- Permutación inicial (IP) de los bits del bloque a cifrar:
2.- Red de Feistel de 16 rondas:

2.1.- Primera iteración:
2.2.- Segunda iteración:
2.3.- Tercera iteración:
2.4.- Cuarta iteración:
2.5.- Quinta iteración:
2.6.- Sexta iteración:
2.7.- Séptima iteración:
2.8.- Octava iteración:
2.9.- Novena iteración:
2.10.- Décima iteración:
2.11.- Undécima iteración:
2.12.- Duodécima iteración:
2.13.- Decimotercera iteración:
2.14.- Decimocuarta iteración:
2.15.- Decimoquinta iteración:
2.16.- Decimosexta iteración:
3.- Permutación final (IP-1) de los bits de la concatenación R16 || L16:
Con lo que el criptograma (C) sería:

- En binario:

C = 1001101111111011111110111111010011010000111110010001011000000100

- En hexadecimal:

C = 9BFBFBF4D0F91604


Lo dicho, en el siguiente post, para comprobar si lo he comprendido y he hecho correctamente, realizaré el descifrado de este criptograma.