Boletín ENIGMA - nº 64
1 Noviembre 2008
Boletín del Taller de Criptografía
de Arturo Quirantes Sierra
Dirección original: http://www.cripto.es/enigma/boletin_enigma_64.htm
TEMAS DE ACTUALIDAD - Más sustos inalámbricos
CRIPTO 101 - Encadenando bloques
CRIPTOGRAFÍA HISTÓRICA - Los primeros criptógrafos - corrección
LIBERTAD VIGILADA - España reconoce su presencia en ILETS
Si
hay algo que mantenía yo con ilusión desde hace tiempo, era que algún día las
máquinas Enigma compradas por Franco aparecerían como por arte de magia.
Descubrí una en el Museo Militar de Madrid. El resto, al menos una buena parte,
aparecieron recientemente en el cuartel general del Ejército español. No vamos a
hablar de ellas hoy, pero palabrita de honor que pronto les dedicaremos el
espacio que se merecen.
En el apartado extremo, desde Viena nos vienen noticias sobre los últimos
avances en criptografía cuántica. Tanto en un caso como en el otro, la moraleja
es la de siempre: !cuánto camino queda aún por delante! Los descubrimientos tipo
"state-of-the-art" (que en usalandés significa algo así como "lo último de lo
último") se suceden mes tras mes, y las sorpresas que nos guarda aún la musa de
la Historia parecen no tener fin.
Entre medias, seguimos con noticias que, sin ser de actualidad, enlazan con
acontecimientos que ya hemos relatado, sean fallos en seguridad inalámbrica o
anuncios de supuestos avances criptográficos para vender más. Creo que este
boletín satisfará a todos, puesto que de todo hablamos hoy.
Por otro lado, en el apartado "mi ombligo y yo", este mes pasado apareció un
artículo dedicado a este que firma ... en una revista tan poco criptográfica
como Más Allá, una publicación mensual de temas de ciencias ocultas. Está
disponible en Internet, y me sacan guapo y todo (http://www.masalladelaciencia.es/historico-de-revistas/numero_236).
Posteriormente, fui entrevistado por dos cadenas de radio para sendos programas
de ocultismo, lo que me hace sospechar que la creencia de que la criptografía es
cosa de brujas sigue estando muy arraigada. !Y se reían de Felipe II cuando
acusó al criptógrafo francés Viete de brujería!
Y, hace tan sólo unos minutos, recibo nuevas de que José Ramón Soler Fuensanta,
amigo de la cripto y de este boletín, va a aparecer en el próximo programa de
Cuarto Milenio. Si esto crea moda, me parece que vamos a tener que
reconvertirnos en parapsicólogos, echar las cartas o algo así. Por de pronto,
justo a continuación tenéis un artículo sobre criptografía wifi que, por pura
casualidad, se titula "más sustos inalámbricos". Criptoterror en estado puro ...
o no tanto. Feliz noche de Halloween.
TEMAS DE ACTUALIDAD - Más sustos inalámbricos
Las redes inalámbricas son un riesgo para la seguridad. El motivo es sencillo:
para acceder a ellas no hay más que poner una antena. Las comunicaciones por
cable requieren que el atacante tenga acceso físico (o bien que sea un gobierno,
y esgrimiendo razones de seguridad obligue a las operadoras a concederle ese
acceso, pero esa es otra historia), pero las ondas pertenecen al primero que las
capte. Los soviéticos lo sufrieron en sus propias carnes. Creyendo que las
microondas no podían ser interceptadas desde el espacio, las usaron para dotar
de cobertura de comunicaciones su vasto territorio. Los norteamericanos, a la
chita callando, ingeniaron una forma de captar dichas ondas, lanzaron al espacio
una red de satélites espía Ryolite, y se pusieron literalmente las botas durante
más de una década.
La contramedida es obvia: cifremos la señal. Y la contramedida a dicha
contramedida también lo es: criptoanalicemos la cifra, ataquemos mediante fuerza
bruta, aprovechemos cualquier vulnerabilidad en el sistema. Los soviéticos
cerraron su ventana de vulnerabilidad hace años, conscientes de lo que se
jugaban. ¿Pero qué hay de todos los usuarios de Internet que usan conexiones
wifi?
Ya en boletines pasados hablamos de fallos asociados al algoritmo WEP, usado
hasta ya mismo para cifrar comunicaciones wifi ("WEP, inseguridad inalámbrica",
Boletín ENIGMA 52, y algunos editoriales). Por desgracia, muchas telecos siguen
dando a sus clientes routers inalámbricos que no aceptan más que el protocolo
WEP, y al usuario medio eso le parece más que suficiente. Afortunadamente,
tenemos el protocolo WPA (Wifi Protected Access), mucho más resistente.
Algún día analizaremos WPA como se merece. Hoy, en cambio, vamos a asustarnos un
poco. Aunque WPA incorpora un proceso de cifrado como WEP, es más fuerte, ya que
usa claves de 128 bits junto con un sistema de verificación de mensajes. Una
versión más avanzada, WPA2, incorpora el algoritmo de cifra simétrica AES, y
cumple totalmente con el estándar 802.11i. Parece que no hay vulnerabilidades
criptográficas, al menos que se sepa a día de hoy. Entonces, ¿por qué una
empresa nos dice que WPA está poco menos que muerto?
La empresa de marras es Elcomsoft, una compañía que lleva casi veinte años
diseñando software para recuperación de datos, o para que nos entendamos, para
romper cifras. Es el tipo de programa que necesita un usuario que ha olvidado su
contraseña para abrir su documento zip, word o de otros tipos. También está
especializada en software de análisis forense, lo que resulta especiamente útil
si el señor Grissom quiere leer los mensajes que oculta el malo en su ordenador.
Los productos de Elcomsoft incorporan métodos de fuerza bruta (probar todas las
contraseñas posibles) y de ataques de diccionario (comprobar si la contraseña se
encuentra en una lista de palabras de uso común). Sus programas forenses llegan
incluso a examinar el disco duro entero, elaborar diccionarios de posibles
contraseñas y probarlas una a una.
Elcomsoft (que, para mayor ironía, es rusa) anunció hace unos días un par de
novedades. La primera es que la nueva versión de su programa de recuperación de
claves (Distributed Password Recovery) puede ahora funcionar en un ordenador a
una velocidad 20 veces superior. ¿Cómo? Pues mediante el ingenioso truco de
aprovechar la potencia de cálculos de los chips (GPU) de las tarjetas gráficas.
Todos estábamos preocupados de cuánto puede hacer la CPU del ordenador, y no
caíamos en la cuenta de que en la actualidad las tarjetas gráficas tienen una
potencia endiablada. De hecho, Elcomsoft afirma que su programa puede probar más
de mil millones de contraseñas por segundo. Esto significa probar todas las
contraseñas posibles de ocho letras en menos de cuatro minutos. ¿Comenzamos a
asustarnos ya?
Bien, en realidad esto no es un problema nuevo. Ya sabemos que la potencia de
cálculo de los ordenadores actuales aumenta que es una barbaridad, y no sólo
ellos sino también cualquier otro cacharro que pueda ejecutar operaciones
matemáticas. En la década de los 90, yo conseguí simular datos de dispersión de
luz mediante la llamada teoría de Mie en una hoja de cálculo; hacer unos meses,
un colega mío lo consiguió usando ... un teléfono móvil. A partir de ahora, los
documentos que ciframos en zip, o los de Office, tendrán que usar contraseñas
más seguras. Qué le vamos a hacer, hoy las ciencias adelantan que es una
barbaridad. Y si bien el paquete completo de programas sobrepasa los mil euros
de precio, también es cierto que existen las redes p2p y la gente dispuesta a
compartir.
Sin embargo, los rusos de Elcomsoft nos han dado un segundo susto. O, al menos,
lo han intentado. Aprovechando que el Pisuerga pasa por Valladolid, se
descuelgan con esto:
"Con la última versión de Elcomsoft Distributed Password Recovery (EDPR), es
ahora posible reventar la proteción WPA y WPA2 en redes Wi-Fi hasta cien veces
más rápido ... sólo necesita interceptar unos paquetes (con cualquier sniffer de
red que pueda exportar datos en format tcpdump) para efectuar el ataque" Es
decir, se atreven incluso a pronosticar la muerte de WPA2, que utiliza el
algoritmo AES de 256 bits.
Bien, un par de cosas. En primer lugar, usar AES no significa gran protección si
todo lo que usamos para activarlo son claves de 6-8 caracteres, y aquí está la
vulnerabilidad de todo lo que protejamos mediante contraseña. EDPR busca
contraseñas en WPA y WPA", igual que lo hace en los documentos de Office.
En segundo lugar, el ataque no es nuevo, en el sentido de que ya se sabía que
esnifar algunos paquetes permitía, en principio, romper el sistema. La cuestión,
por supuesto, estriba en el "en principio". El protocolo WPA necesita, para su
activación, nada menos que 8192 llamadas al protocolo SHA1, lo que significa un
total de 15 millones de operaciones. En un procesador Xeon usando el programa
Aircrack, se pueden hacer unas 650 comprobaciones de contraseña por segundo. Con
el aumento de Elcomsoft, quizá llegue a 10.000-20.000 contraseñas por segundo,
lo que significa siglos para descubrir una contraseña de ocho letras.
Es decir, que su superprograma se meriende mil millones de contraseñas en
ataques a documentos de Office no significa, ni mucho menos, que WPA esté en
riesgo. Más aún, ¿qué "salto cuántico" significa un aumento de veinte, o de
cien? Mucho para mí y mi pequeño portátil, seguro, pero ya hay grandes recursos
a disposición incluso de un usuario individual. Más parece que Elcomsoft haya
querido aprovechar el tirón mediático usando como cebo WPA. Quizá el año que
viene lo intenten con los algoritmos de telefonía GSM: "ahora se pueden
interceptar teléfonos cien veces más rápido".
El problema es que algunos consultores de seguridad han caído en el juego. O al
menos, uno, un tal David Hobson, de la empresa de consultoría de seguridad
Global Secure Systems, quien en diversos medios de Internet se ha mostrado muy
preocupado, hasta el punto de afirmar que "el descifrado de los sistemas WPA y
WPA2, mediante fuerza bruta, usando procesamiento en paralelo ha estado en el
horizonte de las posibilidades teóricas desde hace algún tiempo". Si usted,
querido lector, sabe leer entre líneas, habrá visto que eso y nada es lo mismo.
Es como decir que, si juego cinco números a la lotería en lugar de uno, la
posibilidad de que me toque es más probable.
No olvidemos, por otro lado, que la contraseña usada en las redes wifi puede ser
mucho más larga que ocho caracteres. La mía tiene ... hmm, mejor no os lo digo.
No es necesario que la introduzcamos cada vez que nuestro wifi se conecta a la
red, y podemos guardarla con comodidad dentro de un CD o un lápiz USB para
cuando la necesitemos. El avance (por llamarlo así) de Elcomsoft no sirve más
que para los que usen una contraseña débil y corta.
Es posible que algún día aparezca un método de reventar WPA. A la larga, me
huelo que la facilidad con que se captan paquetes del éter puede acabar con
estos protocolos de cifrado. Pero de momento, WPA parece resistir, y no debemos
caer en el pánico creado por una empresa que vende software.
CRIPTO 101 - Encadenando bloques
Existen dos grandes tipos de algoritmos de cifrado simétrico: de flujo y de
bloque. Los algoritmos de bloque (Block Ciphers) operan con "bloques" de varios
bits, en tanto que los algoritmos de flujo (Stream Ciphers) operan sobre bits
individuales. Un algoritmo de flujo sería algo así como un taxi, que en cuanto
el viajero sube sale disparado. Por contra, el algoritmo de bloque sería como un
autobús que no sale de la estación hasta que todos los asientos estén ocupados.
Ambos tipos de algoritmos tienen sus peculiaridades, y hoy vamos a ver los
correspondientes a algoritmos de bloque.
La mayoría de los algoritmos simétricos que nos suenan son de tipo bloque: DES,
IDEA, AES. Tienen asignado un tamaño de clave, que también es el tamaño del
texto llano que procesa. Por ejemplo, DES tiene una clave de 64 bits, o lo que
es lo mismo, de 8 bytes. Esto significa que toma un mensaje M de 64 bits y lo
cifra mediante una clave k para dar un bloque cifrados C de 64 bits de tamaño.
Matemáticamente, podemos representar el algoritmo de cifra como una función E
que depende tanto del mensaje M como de la clave k: C=Ek(M). Como el algoritmo
es simétrico, la función de descifrado es igual que la de cifrado, de forma que
M=Ek(C).
Sencillo hasta aquí, ¿no? Sin embargo, cuando tenemos un mensaje más largo, las
cosas se complican. Por supuesto, podemos dividirlo en bloques de N bits: M1,
M2, M3 ... Mn. Pero ahora, el resultado de cifrar el bloque Mn puede depender
tanto de la función E y de la clave k como de los bloques que hemos cifrado
anteriormente. Es decir, la ruta del autobús 13 dependerá del recorrido que
hayan efectuado los autobuses que le precedieron. El modo en que tal dependencia
sucede puede afectar a las prestaciones de la cifra, pero también -lo que es más
grave- a la seguridad del sistema.
Vamos a ilustrarlo. Seguro que a más de uno le ha resultado raro eso de que el
cifrado de un bloque dependa de los bloques anteriores. ¿Por qué complicarse la
vida? ¿No podemos, sencillamente, cifrar cada bloque con la clave y dejarnos de
monsergas? Sí, podemos. De hecho, ese es el denominado Modo de Libro de Código
Electrónico (Electronic Codebook Mode, ECB). En el EBC, el cifrado de cada
bloque es independiente, como si los demás no existiesen:
C1 = Ek(M1)
C2 = Ek(M2)
C3 = Ek(M3)
...........
Cn = Ek(Mn)
Es el modo que, a priori, nos parece el más natural. Cada bloque de texto llano
se cifra de modo independiente, lo que resulta muy útil al cifrar bases de datos
de acceso aleatorio, ya que no necesitamos cifrar de nuevo toda la base cuando
añadimos, alteramos o borramos parte de ella. Es la forma más rápida de cifrar,
y la verdad, uno al principio puede plantearse por qué pensar siquiera que hay
otras formas de cifrar.
El problema con el modo de encadenado EBC (es decir, cuando no hay modo
encadenado en absoluto) es que resulta vulnerable a ciertos tipos de ataques.
Por fijar conceptos, imaginemos una base de datos con la lista de clientes de un
banco: nombre, número de cuenta, saldo. Supongamos que el criptoanalista tiene
acceso a toda la base de datos (cosa que, a tenor de las noticias sobre robos de
bases de datos, fallos de vulnerabilidad y pérdidas accidentales, cada vez es
menos raro). Digamos que de algún modo, el atacante tiene al menos parte de la
información de dicha base de datos en texto llano. Eso le permite conocer, o al
menos deducir, parte de los datos. Por ejemplo, digamos que examina la base de
datos, cifrada, y comprueba que hay diversas cadenas alfanuméricas que se
repiten. ¿Puede tratarse de saldos en números redondos? Quizá "928hng4l"
significa "diez mil", o "kkwg972c" es un nombre de pila común.
Puede que, rebuscando en mi basura, haya podido relacionar mis datos bancarios
con ciertos textos cifrados en la base de datos. Voy a simplificar al máximo.
Digamos que el lunes, yo soy el único cliente del banco que hace una operación
de retirada de fondos entre las 10:05 y las 10:06 de la mañana. El enemigo
accede a la base de datos y averigua cuál ha sido la única línea de la base de
datos que ha sido alterada. De ese modo, o mejor dicho, de forma similar pero
más compleja, un atacante puede hacer estudios estadísticos sobre el texto
cifrado para obtener al menos parte de la información sin saber la clave.
He aquí el esquema de un ataque alternativo. Imaginemos que el Banco A envía un
mensaje electrónico al Banco B, en el que se detalla una transferencia a un
cliente de este último. Por algún motivo, todo el paquete de datos está cifrado
con la misma clave. Los datos de la transferencia están divididos en bloques: un
bloque para el nombre del banco emisor, uno para el del banco receptor, tres
para el del nombre del destinatario, uno para el de la cantidad depositada y dos
para el del número de cuenta final. Es decir, algo así como EE-RR-DDD-M-CC
Ahora bien, imaginen que yo quiero enriquecerme rápidamente. Así haré lo
siguente. En primer lugar, ordeno una transferencia legítima EE-RR-DDD-M-CC
desde mi cuenta en A a mi cuenta en B, y la intercepto. A continuación,
intercepto una transferencia de otra persona cualquiera, digamos ee-rr-ddd-m-cc,
le quito los bloques correspondientes al destinatario y al número de cuenta por
los míos, y los envío. Esa transferencia fraudulenta (digamos ee-rr-ddd-M-CC).
De ese modo, un desconocido (ddd) a quien no tengo el gusto de conocer ha
transferido sobre el papel (bueno, sobre el cable) una cantidad de dinero M que
ni siquiera conozco a mi cuenta. Fíjense que no conozco la clave, no sé quién es
mi anónimo benefactor, y ni siquiera sé la cuantía de la transferencia. Por
supuesto, tarde o temprano el banco receptor se dará cuenta de que el banco
emisor no paga, se dirigirán al cliente y éste dirá que no es cosa suya, pero
para entonces yo ya he vaciado mi cuenta y me he largado a las Seychelles, desde
donde les estoy escribiendo bajo el nombre supuesto de Arturo Quirantes.
Es decir, el mero hecho de que un mensaje esté cifrado no lo protege contra
diversos tipos de fraude. Podemos alterar la estructuras de datos, montar
ataques de denegación de servicio, el caso es echarle imaginación. A ver qué les
parece este: tomo una de esas transacciones legítimas y la reproduzco un millón
de veces. El banco receptor no sabe de dónde viene esa montaña de dinero, pero
se corre la voz y su cotización se dispara; por contra, el del banco emisor se
hunde ante las noticias de retiradas masivas de fondos. Al final todo acaba
volviendo a la normalidad, pero mientras tanto yo me he forrado comprando
acciones de un banco y vendiendo las del otro.
De acuerdo, los bancos no son tontos. Hay sistemas que ponen en marcha para
evitar este tipo de fraudes. Pero permanece el hecho de que permitir el cifrado
de bloques de datos de forma independiente es un riesgo de seguridad. Por
ejemplo, los bloques de datos pueden ir acompañados de un sello temporal o un
código de autenticación de mensajes. Otras aplicaciones tales como bases de
datos aleatorios pueden usar ECB sin problemas. En el caso de una partición
cifrada, existe un procedimiento que veremos algo más adelante.
También podemos ir un paso más allá y usar el encadenado, es decir, hacer que el
bloque idel mensaje dependa de lo que había en el bloque i-1. De esta forma, si
intento copiar y pegar el saldo de Bill Gates, el resultado será una ristra sin
sentido. De hecho, el encadenado hace que el bloque cifrado Ci dependa del
bloque cifrado Ci-1, que a su vez depende del Ci-2, y así sucesivamente. Un
problema que aparece es que un fallo en uno de los bloques cifrados (por una
mala encriptación, fallos en el hardware, el software o la transmisión) puede
propagarse a los demás bloques. Se conocen diversos modos de encadenamiento,
cada uno de los cuales tiene sus ventajas e inconvenientes.
En primer lugar tenemos el modo de Encadenado de Bloque Cifrado (CBC, Cipher
Block Chaining). En el CBC, lo que se cifra no es el bloque Mi de texto llano,
sino una "suma" entre Mi y el bloque cifrado anterior Ci-1:
Ci = Ek(Pi + Ci-1)
En la fórmula anterior, "i-1" es un subíndice, mientras que "+" es una operación
denominada XOR (Exclusive-OR). XOR, aplicado a dos bits, nos da 0 si ambos bits
son iguales, y 1 si los bits son distintos. Esto es: 0+0=1+1=0, 0+1=1+0=1. Si se
fijan bien, es una suma sin acarreo. Esto significa que, en el modo CBC, "xoreamos"
el bloque cifrado anterior con el bloque llano actual, y a lo que sale le
aplicamos el algoritmo de cifrado. La operación inversa, el descifrado, se hace
de la siguiente forma:
Pi = Ci-1 + Ek(Ci)
Ya hemos mencionado algunas de sus ventajas. Como Ci depende de Ci-1, no podemos
sustituir un bloque cifrado por otro sin que el resultado pase inadvertido.
Sigue existiendo el problema de que dos textos idénticos, sometidos a la misma
clave, nos da el mismo texto cifrado. Peor aún, dos textos con el mismo comienzo
darán como resultado el mismo texto cifrado hasta el punto en que comiencen las
diferencias. Este problema es muy habitual en archivos con idénticos
encabezamientos (documentos de Word, cartas estereotipadas, mensajes de e-mail,
etc), y nos recuerda que incluso en el mundo electrónico de hoy sigue siendo
válida la máxima de evitar las regularidades. Que ya no se use la máquina Enigma
no significa que comenzar los mensajes con "tengo el gusto de comunicarle..."
sea una buena idea. Para evitarlo, una práctica habitual consiste en insertar al
principio del texto una ristra de datos aleatorios llamada Vector de
Inicialización (IV). El IV no significa nada, no aparece en el texto llano, y su
única razón de ser es hacer que cada texto sea único.
Hay un precio a pagar. En el modo ECB, era posible paralelizar el proceso. Es
decir, si necesitamos un centenar de datos en una base de acceso aleatorio,
podemos irlos descifrarlos en paralelo. Pero el descifrado en modo CBC ha de
hacerse en serie, manipulando los bloques de datos de uno en uno. En cuanto a la
propagación de errores, existe pero es pequeña. Si en modo ECB un error en un
bloque cifrado impide leer un bloque en texto llano, el mismo error en modo CBC
afecta a dicho bloque y a un bit del bloque siguiente. Nada más. Se dice que el
modo CBC de autorrecuperativo, lo que significa que después de esos dos bloques
erróneos el sistema sigue descifrando textos de forma normal. También hay que
tener en cuenta que un atacante puede añadir bloques de datos si éstos se
colocan al final del texto o mensaje.
Un problema común a los modos ECB y CBC es el de sincronía. Si, por error, se
introduce o se pierde un bit del conjunto de datos cifrados (por una transmisión
errónea, por ejemplo), el texto llano que se obtiene resulta ilegible. Si no se
introducen técnicas capaces de detectar y corregir variaciones en el texto
cifrado, un sólo bit alterado nos convertirá el resto del texto cifrado en
basura. Existe una variación del modo CBC en la cual el texto llano se puede ir
cifrando en bloques más pequeños. Es decir, si el algoritmo de cifrado funciona
en bloques de 128 bits, el modo CBC nos permite cifrar en bloques de 64 bits, o
de 16, o incluso de uno sólo. Este modo, llamado Modo de Retroalimentación
Cifrado (CFB, Cipher-FeedBack mode), es más complejo, pero elimina los errores
de sincronización. Otra variante, llamada Modo de Retroalimentación de Salida (OFB,
Output-FeedBack mode), es algo más sencilla que la CFM. Tiene la ventaja que el
error en un bit cifrado solamente afecta a un bit de texto llano -lo que cierra
las puertas a algunos tipos de ataques-, pero también tiene errores de
sincronización: un sólo bit añadido o eliminado en el mensaje cifrado, y estamos
fritos.
Con todo ello, las recomendaciones de Bruce Schneier en su libro "Applied
Cryptography" sobre los cuatro modos son los siguientes:
- ECB. Es el más simple y rápido, pero también el más vulnerable. No se
recomienda para cifrar mensajes,
- CBC. Es el mejor para cifrar archivos, ideal para aplicaciones basadas en
software (como bases de datos).
- CFB. Es el modo "de rigueur" para cifrar flujos de datos transmitidos, cuando
cada carácter ha de ser tratado individualmente, como los enlaces entre servidor
y terminal. Suele usarse en sistemas de alta velocidad donde no se puede
permitir ninguna propagación de errores.
- OFB. Muy bueno en situaciones donde pueda haber errores, ya que no los
propaga.
Visto lo visto, nos queda claro que el modo ECB es el menos seguro, ya que entre
otras cosas permite notar patrones en el texto cifrado. Eso nos permite poder
entender mejor un artículo criptográfico que apareció recientemente, y que ha
provocado mucho revuelo. Una de las aplicaciones de ECB es el cifrado de
volúmenes cifrados. Tales bichos son, sencillamente, grandes archivos cifrados
que, al descifrarlos, se convierten en carpetas enteras (incluso unidades de
disco virtuales) en nuestro disco duro. No es factible usar otros modos de
encadenamiento en este caso, porque de hacerlo el sistema tendría que re-cifrar
todo el volumen cada vez que yo modifique algún archivo de éste, convirtiendo
así un volumen de acceso aleatorio en uno de acceso secuencial, mucho más lento
de manejar.
Puesto que el modo EBC, como hemos visto, es vulnerable, los fabricantes
introducen añadidos tales como usar una clave que cambie para cada posición del
volumen, o de algún modo hacer que el proceso de cifrado, aun con la misma
clave, sea dependiente de la posición en el volumen cifrado. Sin embargo, seamos
sinceros, ¿cuántos de los usuarios de este tipo de cifrado conoce este tipo de
detalles. Yo mismo me he tenido que empollar el libro del tito Bruce, lo
reconozco. Así que, si alguien dice que puede extraer información de una
partición cifrada, nos entra el pánico.
Algo así pasó hace poco cuando C. B. Roellgen, de la empresa PMC Ciphers Inc,
escribió un artículo con el título de "Visualización de debilidades potenciales
de implementaciones existentes de cifrado en software comercial para disco". El
autor muestra cómo una imagen cifrada en modo ECB permite adivinar contornos de
la imagen original. Para ello, toma una fotografía reducida a cuatro colores:
blanco, negro y dos tonos de gris. Al cifrar con AES, se observa cómo las
principales características de la foto son aún visibles. El truco consiste en
que, al usar ECB puro y duro, las zonas de color uniforme se convierten en el
mismo tono de "color cifrado".
Es decir, nos están mostrando la obviedad de que iguales bloques de texto llano
se convierten en bloques de texto cifrado iguales a su vez entre sí. Pero claro,
si no sabemos la letra pequeña, lo único que vemos es una foto cifrada cuyos
contornos siguen siendo visibles aunque de forma más borrosa (lo que se debe a
que hay que tomar un puñado de bits para formar un bloque para cifrar). Cuando
utilizan un modo ECB combinado con un parámetro dependiente de la posición de
cada bit en la foto, la fotografía se convierte en un conjunto de puntos
aleatorios sin patrones que podamos visualizar. Todo ello acompañado de código
fuente para que podamos comprobarlo en caso de duda.
¿Por qué publica este investigador lo evidente? En mi opinión, para asustar. El
autor, dando un paso más, afirma lo siguiente. Imaginemos dos volúmenes
cifrados, el original (1) y una copia exacta (2). El volumen 1 contiene la
fotografía, en tanto que el volumen 2 no contiene nada, solamente ceros. Lo que
dice este señor es que podemos restar ambos volúmenes (es decir, hacer un XOR
entre cada bit del volumen 1 y el bit de la misma posición en el volumen 2), y
al hacerlo aparece el contorno de la fotografía, más o menos reconocible.
No es difícil ver por qué. Si la fotografía sólo tiene cuatro colores, uno de
ellos será el blanco, que representamos con ceros. En el volumen 1, por tanto,
las partes de la fotografía en blanco se cifrarán de igual forma que los bits
del volumen 2 que se encuentren en la misma posición. Y, al hacer un XOR, esas
partes aparecen. En el artículo, lo sacan de color negro (restan en lugar de
sumar), pero las partes que aparecen son las blancas: la cara de la chica y su
camiseta. El resultado será igual si usamos ECB con una clave dependiente de la
posición, porque estamos comparando bits en la misma posición en ambos
volúmenes.
El propio artículo reconoce a las claras que "es la consecuencia lógica de
cifrar información idéntica con idéntica clave". De hecho, esto es solamente
posible porque el volumen cifrado 2 no fue creado, sino copiado, lo que hace que
tenga tanto la misma clave como el mismo vector de inicialización (IV) del
volumen 1. De haber creado el volumen 2 independientemente y haberlo dejado
vacío, esto no hubiera sido posible. A fin de cuentas, no se suelen crear
volúmenes nuevos mediante copypaste.
Ahora es donde viene el motivo. Todo el artículo está enfocado a presentar un
problema y, al final de todo, afirmar que hay un programa llamado TurboCrypt,
cuya última versión evita este problema. Este señor trabaja, como hemos dicho,
para PMC Ciphers. ¿Y adivinan qué empresa fabrica TurboCrypt? !Premio!
La verdad es que todo el tema de PMC y TurboCrypt es hilarante. Cuando leí el
artículo por primera vez, me sonó un poco raro. Reconozco que me perdí en el
artículo, parte por el rollo de código fuente que incluyen (innecesariamente,
creo yo), parte por la sensación de estar leyendo cómo inventaban la rueda.
Cuando le hice notar a Bruce Schneier sobre el artículo, su respuesta fue
tajante: "Sólo están notando patrones cuando alguien cifra en modo EBC. Nada
nuevo ... y usar ECB es una bobada". Al día siguiente, publicó el asunto en su
blog (http://www.schneier.com/blog/archives/2008/10/new_attack_agai.html,
se incluye enlace al artículo de PMC) donde lo calificaba de "intento descarado
de atraerse publicidad". Ya en 2003, Bruce habló de PMC en estos términos:
"PMC Ciphers. La descripción de la teoría está tan llena de
pseudo-criptografía que es divertida de leer. Las hipótesis se presentan como
conclusiones. La investigación actual se especifica mal o se ignora. El primer
enlace es un artículo técnico con cuatro referencias, tres de ellas escritas
antes de 1975. ¿Quién necesita treinta años de investigación criptográfica
cuando tienes teoría de cifrado polimórfico?"
¿Cifrado polimórfico? Pues sí que suena raro. De hecho, tan raro que en cuanto
abrí la página de PMC Ciphers
http://www.turbocrypt.com comencé a oler a "aceite de serpiente". Visto cómo
son los americanos, no resulta raro toparse, lo primero de todo, con una foto de
la habitual pelirroja escotada (la misma del artículo, por cierto). También
podemos considerar como exageración comercial las frases estilo "La herramienta
definitiva ... ninguna agencia gubernamental de este mundo podrá jamás reventar
TurboCrypt". Menos serio parece el concurso "rompa nuestro sistema y le daremos
un pastón", que incluye la típica perorata sobre cuantísimas claves posibles
habría que probar para vencer al sistema mediante fuerza bruta.
Pero cuando leemos los detalles de su Cifrado Polimórfico (PolyMorphic Cipher, o
PMC) ... algunos detalles son para echarse a reír, o cuando menos, a uno se le
queda cara de bobo. En primer lugar, se supone que su cifrado polimórfico, de
1024 bits, es tan estupendo que uno puede usar en su lugar AES "si el usuario
tolera una seguridad menor" (TurboCrypt puede usarse con AES o con PMC, y la
empresa afirma que los usuarios prefieren PMC en un 80%). En otro lugar, dice
que su PMC se basa en cuatro algoritmos seguros (AES Rindjael, AES Twofish, RC6
y Mars), del que el usuario escoge uno; luego toma una especie de generador de
contraseñas y listo. En otro lugar, dicen que el sistema
toma dos contraseñas y las mete en una función hash. Parte del resultado se usa
!para compilar código máquina del algoritmo de cifra!
Lo más llamativo de TurboCrypt, en mi opinión, es la forma en que se picaron con
Bruce Schneier. El enlace que invita a romper su cifra dice "Intente hacerlo
mejor que Bruce Schneier. Rompa el Cifrado Polimórfico". Justo encima, otro
enlace nos lleva a una nota de la empresa en la que, entre otras cosas, nos
recuerda que la empresa en que traba Bruce, BT Counterpane, "es competidora de
PMC Ciphers, Inc. y que es improbable que alguien con conexiones con los
militares de EE.UU. esté realmente interesado en hacer públicos algoritmos de
cifrado realmente seguros".
Frente a los ataques de Schneier de 2003, PMC Ciphers afirma que la NSA usa su
sistema de cifra, así que ha de ser bueno; y que, lo mismo hasta lo han hecho
bien y todo. Llegan incluso a apoyar los algoritmos propietarios (esto es,
secretos) y a recelar incluso del algoritmo de cifra AES. ¿El motivo? La NSA
tiene algoritmos propietarios, así que han
de ser algo bueno. Y aluden incluso a las fuerzas del mercado:
"¿Cuántos individuos y empresas van a invertir el dinero, tiempo y esfuerzo
necesario para desarrollar nueva tecnología de cifrado, si luego lo regalan? La
verdad pura y dura es que el capitalismo, el potencial para hacer beneficios, es
una de las mayores fuerzas que impulsan el desarrollo de nuevas tecnologías.
Eliminar esta fuerza del desarrollo del cifrado sólo nos hará más débiles a
largo plazo"
A la vista de la tormenta bursátil que nos azota estos días, no creo que el
argumento les sirva de algo. Y espero que eso que denominan "activos tóxicos" no
se refiera al aceite de serpiente de ciertas empresas de encriptación.
CRIPTOGRAFÍA HISTÓRICA - Los primeros criptógrafos - corrección
Como algunos lectores han notado, el artículo "Los primeros criptógrafos" del
mes pasado contiene algunas erratas. Los diablillos del copypaste hicieron de
las suyas, sustituyendo una "e" en lugar de "L". Entre otras cosas,
criptografiaron de mala manera el cifrado atbash, que debería ser como sigue:
"La transformación de Babilonia en Sesac se hizo mediante una sustitución
monoalfabética llamada "atbash". En una sustitución monoalfabética, cada letra
se convierte en un solo elemento cifrado (que puede ser otra letra, un número,
un signo o cualquier combinación de los anteriores). En el atbash, se trata de
sustituir el alfabeto mediante un alfabeto escrito en orden contrario. Usando el
alfabeto latino actual, tendríamos:
Texto
llano: A B C D E F G H I J K L M N O P Q R S T U V X Y Z
Texto cifrado: Z Y X V U T S R Q P O
N M L K J I H G F E D C B A
De esta forma, BABILONIA se convertiría en YZYQNKLQZ. En el alfabeto hebreo,
BABEL (BBL) se convierten en SH-SH-K (Sheshak o Sesac). Una transformación
similar convierte los habitantes de "leb kamai" en "kasdim" (caldeos) en
Jeremías 51:1. Existe en la Biblia una segunda transformación, denominada "albam",
similar al atbash. Junto con el atbah, forman un trío de sustituciones conocidas
en el lenguaje hebreo desde la antigüedad. Por ese motivo, no puede considerarse
un lenguaje criptográfico ya que la "clave" para cifrar descifrar es conocida e
inalterada."
LIBERTAD VIGILADA - España reconoce su presencia en ILETS
[Extraído del libro "Libertad Vigilada", de Nacho García Mostazo, con permiso
del autor]
Segunda parte, capítulo 16:
El 10 de abril de 2002, José Luis Centella, diputado de Izquierda Unida en el
Congreso, presentó una pregunta parlamentaria al Gobierno sobre ILETS y la
participación española en este "seminario". Centella afirmaba que, "según
diversos informes del Parlamento Europeo, España participa desde 1993 en
reuniones internacionales de seguridad de las telecomunicaciones denominadas
ILETS" y aseguraba que "el Congreso de los Diputados, hasta el momento, no ha
tenido conocimiento alguno de tales encuentros", pese a que habían "asistido
representantes del Reino de España", por lo que pedía al Ejecutivo que explicara
su implicación concreta en ILETS. [1]
La respuesta tardó casi dos meses en llegar. Lleva fecha del 7 de junio de 2002,
aunque no se publicó en el Boletín Oficial de las Cortes Generales hasta el 1 de
julio. El Ejecutivo afirmaba, intentando quitarle importancia, que "ILETS es una
reunión informal en la cual participan, desde el año 1993 y por invitación,
policías de los países de la Unión Europea y terceros países, y en la que se
trata la problemática de la interceptación legal de los nuevos sistemas de
telecomunicaciones". En concreto, "acuden funcionarios del Cuerpo Nacional de
Policía especialistas en materia de telecomunicaciones e interceptación legal de
las mismas". En cuanto a la participación española, el Gobierno matizaba
afirmando que "están representadas las agencias invitadas, no los distintos
países". [2]
A continuación, explicaba que, "dentro del seminario, existe un Comité Técnico
Permanente (STC) y un Grupo de Trabajo de Política y Legislación (LPWG), cuyos
trabajos se centran en la puesta en común de los desarrollos nacionales en el
ámbito general de la interceptación de las comunicaciones, tanto desde el punto
de vista de las soluciones técnicas, como en materia de legislación. Asimismo,
estos grupos están en permanente comunicación con las agencias de normalización
europeas ETSEI (Instituto Europeo de Normalización de las Telecomunicaciones) y
estadounidense CALEA (Acta de Asistencia en Comunicaciones para las Agencias de
Interceptación en Estados Unidos), donde se trata de defender posiciones en
común, como puede ser la Resolución del Consejo de 17 de enero de 1995 sobre la
interceptación legal de las telecomunicaciones". El Ejecutivo se refería a la
Resolución del Consejo que adoptó el documento "IUR 1.0" elaborado por ILETS.
Como se ha mencionado, este documento se aprobó en secreto el 17 de enero de
1995, pero no se publicó en el Diario Oficial de las Comunidades Europeas hasta
pasados 22 meses, el 4 de noviembre de 1996. [3]
Centella también preguntaba si se había celebrado alguna reunión de ILETS en
España, a lo que el Gobierno contestó que "en España no ha tenido lugar ninguna
reunión de ILETS como tal pero, en octubre de 1998, se reunieron en Madrid, en
instalaciones de la Dirección General de la Policía, los dos Grupos de Trabajo
anteriormente mencionados", lo cual venía a confirmar lo revelado por Duncan
Campbell sobre la reunión en Madrid para preparar la revisión del documento "IUR
1.0". En su respuesta, el Ejecutivo también explicaba que estos encuentros
"constituyen una herramienta más del trabajo para la mejora de la eficacia en la
función policial. Por ello, se intenta participar en todas las reuniones donde
se traten temas de interés para la labor policial al efecto de estar
perfectamente informados de los avances técnicos y legislativos a nivel
mundial". En cuanto a la necesidad manifestada por el diputado de Izquierda
Unida para que el Gobierno mantenga informado al Parlamento sobre estas
cuestiones, la respuesta fue contundente: "Su celebración no está sujeta a
especiales requisitos en cuanto a comunicaciones [...], ni en cuanto al
suministro de información que proceda a los organismos institucionales que la
demanden."
Por último, José Luis Centella preguntó sobre la adaptación de las resoluciones
adoptadas en ILETS a la legislación española. Aunque el Gobierno ya había
mencionado la Resolución del Consejo de la Unión Europea del 17 de enero de
1995, amplió esta información detallando cuál es el procedimiento habitual que
se sigue: "Los temas tratados se llevan al Consejo Europeo a través de los
Grupos de Trabajo de Cooperación Policial, a los que pertenecen muchos de los
representantes de las agencias que acuden a ILETS." Así pues, el Ejecutivo
estaba revelando que los funcionarios de los Grupos de Trabajo de Cooperación
Policial en la Unión Europea, que son quienes redactan los informes "ENFOPOL",
son los mismos empleados públicos que también acuden a las reuniones de ILETS,
lo cual es especialmente importante para la investigación que nos ocupa, ya que
confirma la relación directa del FBI y la NSA en la redacción de los documentos
aprobados por las instituciones de la UE.
Pero de todas las preguntas formuladas por el diputado de Izquierda Unida, el
Gobierno sólo dejó una sin contestar: ¿Quién organiza estos encuentros? Gracias
al Parlamento Europeo podemos saber que ILETS fue una idea del FBI en
colaboración con la NSA. En su respuesta, el Ejecutivo sí explicó que los
funcionarios policiales acuden a ILETS "por invitación" y en compañía de sus
homólogos de otros Estados de la Unión Europea y de "terceros países", pero no
especificó de qué países y, sobre todo, no dijo que la idea partió de Estados
Unidos, la nación responsable de la mayor red global de interceptación de las
comunicaciones. Es posible que ese dato no tuviera demasiada relevancia para el
Gobierno español, aunque también podríamos pensar que prefirió ocultarlo, quizá
por su, cada vez más, creciente "amistad" con Norteamérica.
[1]. Documento 184/027764. Pregunta escrita al Gobierno. Boletín Oficial de las
Cortes Generales. Serie D, número 342, de 24 de abril de 2002. P. 44.
[2] Documento 184/027764. Respuesta escrita del Gobierno. Boletín Oficial de las
Cortes Generales. Serie D, número 381, de 1 de julio de 2002. Pp. 128 y 129.
[3]. NOTA: Hemos respetado la cita literal del Gobierno, aunque comete varios
errores graves en ese párrafo. Cuando se refiere a CALEA, el Ejecutivo se
equivoca porque ese término se refiere a la Ley de Asistencia en Comunicaciones
para los Cuerpos de Seguridad norteamericanos, no a una agencia estatal de
normalización en Estados Unidos. Asimismo, cuando cita a la agencia europea
ETSEI, probablemente se trate de una equivocación en la transcripción, pero el
acrónimo correcto es ETSI (European Telecommunications Standards Institute).
El boletín ENIGMA es una publicación gratuita del Taller de
Criptografía, y se rige por las normas de la licencia de Creative Commons
Reconocimiento-NoComercial-CompartirIgual. Se permite su libre copia,
distribución y comunicación para fines no lucrativos, citando nombre y
referencia.
Para más información, véase la licencia Creative Commons en sus formas reducida
y completa:
http://www.cripto.es/licencia/deed.es.htm
http://creativecommons.org/licenses/by-nc-sa/2.5/es/legalcode.es
PARA DARSE DE ALTA: envíe un mensaje a la dirección alta arroba cripto.es
añadiendo las palabras alta_enigma en el asunto (subject).
PARA DARSE DE BAJA, envíe un mensaje a la dirección baja arroba cripto.es
añadiendo las palabras baja_enigma en el asunto (subject)
Para comentarios a este boletín (dudas, preguntas, consultas, críticas,
noticias, colaboraciones, etc.), estoy a su disposición en la dirección
noticias arroba cripto.es
Página del Boletín Enigma (incluyendo números atrasados):
http://www.cripto.es/enigma.htm
(c) Arturo Quirantes 2007
Vuelta a la Página principal del Boletín ENIGMA