Los sistemas de cifrado simétrico actual pueden dividirse en dos tipos: algoritmos de flujo (stream ciphers) y algoritmos de bloque (block ciphers). Los primeros manipulan el texto cifrado bit a bit, en tanto que los segundos trabajan con “bloques” de varios bits. Podemos visualizar un algoritmo de flujo como un taxi, que sale disparado en cuanto el viajero se sube en él. 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.

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, y un tamaño de bloque (algunos algoritmos tienen varios tamaños posibles de bloque). 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 cifrado C de 64 bits de tamaño. En este caso, el tamaño de la clave y el del bloque coinciden, pero no es una condición que tenga que cumplirse necesariamente en otros algoritmos.

Matemáticamente, podemos representar el proceso 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í. Pero ¿qué hacemos si el mensaje es mayor que un bloque? Lo lógico sería trocear el mensaje en bloques de, digamos, N Bits:

C1=Ek(M1)

C2=Ek(M2)

…

Ch=Ek(Mh)

Este modo de cifrar bloques de bits es el denominado Modo de Libro de Código Electrónico o ECB (Electronic Codebook Mode). Como han visto, en el ECB cada bloque se cifra de modo independiente, como si los demás bloques no existiesen. Es el modo que, a priori, nos parece más natural. Resulta especialmente útil a la hora de cifrar grandes bases de datos, ya que no necesitamos cifrar todo de nuevo cuando añadimos, alteramos o borramos información. 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. Por eso, ECB es el modo habitual en que muchos creadores de software incorporan sistemas de cifrado.

El problema con el modo de encadenado ECB es que resulta vulnerable a ciertos tipos de ataques. En este punto, el término “ataque” debe entenderse no en sentido estrecho (descifrar un mensaje) sino en el de dar a un intruso cualquier tipo de ventaja. Puede que un atacante no pueda leer un mensaje, pero si es capaz de insertar o sustituir parte del mensaje cifrado, eso también vale.

Para ilustrar la vulnerabilidad del modo ECB, vamos a imaginar 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 cifrada (cosa que, a tenor de las noticias sobre robos de bases de datos, fallos de vulnerabilidad y pérdidas accidentales, resulta cada vez menos raro). Como toda la base de datos está cifrada con la misma clave, las redundancias que aparezcan pueden dar información sobre el contenido.

Por ejemplo, digamos que el atacante 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 el enemigo haya averiguado que yo fui el único cliente del banco online que realizó una retirada de fondos entre las 9:56 y las 9:57 de la mañana, y de ese modo averiguar cuál fue la única línea de la base de datos que ha sido alterada; eso le dice que 9n1ff2ka es el resultado de cifrar mi nombre.

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 suyo. 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 nombre del destinatario, uno para la cantidad transferida y dos para el número de cuenta de destino: ERDDDMCC.

En esta ocasión, yo soy el atacante (qué quieren, me han vuelto a recortar el sueldo y hay que llegar a fin de mes como sea). En primer lugar, ordeno una transferencia legítima desde mi cuenta en el banco A a mi otra cuenta en el banco B, y grabo la transmisión ERDDDMCC. A continuación, intercepto otra transferencia, digamos erdddmcc, le quito los bloques correspondientes al banco de destino, nombre de destinatario y número de cuenta, los sustituyo por los míos, y envío el resultado eRDDDmCC. De ese modo, un desconocido a quien no tengo el gusto de conocer ha transferido sobre el papel (bueno, sobre el cable) una cantidad de dinero m a mi cuenta CC.

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. 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.

Por supuesto, los ataques que les estoy describiendo aquí son elementales, y el sistema bancario tiene mecanismos para detectar y perseguir este tipo de fraudes, así que recuerde: no lo intente usted en casa. Aun así, estos ejemplos ilustran el hecho de que el cifrado no es una herramienta mágica que nos protege de todos los problemas. Puede ocultar información hasta cierto punto, pero no evita ataques de repetición o alteraciones de datos. Es necesario algo más.

Una de las soluciones es olvidarnos del cifrado en modo ECB. Si conseguimos que cada bloque cifrado dependa de otros bloques de texto cifrado, será más difícil engañar al sistema mediante trucos como los que acabo de mostrarles. Si se fijan ustedes, la construcción de paredes sigue un principio similar. A nadie se le ocurre limitarse a apilar ladrillos unos justo encima de los otros, formando torres de ladrillos que pueden fácilmente venirse abajo. En su lugar, los ladrillos se entrelazan unos con otros, lo que hace que la pared sea mucho más resistente.

Algo así es lo que sucede con el encadenado de bloques en un sistema de cifrado. Ahora, el resultado de cifrar el bloque de texto Mn dependerá de los bloques que hemos cifrado anteriormente. Es decir, la ruta del autobús en que viajo dependerá del recorrido que hayan efectuado los autobuses que le precedieron. El encadenado hace que el bloque cifrado C[i] dependa del bloque cifrado C[i-1], que a su vez depende del C[i-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. El primero es el llamado Encadenado de Bloque Cifrado, o CBC (Cipher Block Chaining). Funciona a base de tomar el bloque cifrado anterior, sumarlo al bloque de texto nuevo, y cifrar el resultado:

En este caso, la “suma” es la operación XOR (que hemos denotado con el símbolo ⊕), y que tiene la propiedad de que es su propia operación opuesta, es decir, la suma es igual que la resta. La operación de descifrado se haría de forma similar:

Ya hemos mencionado algunas de sus ventajas. Como C[i] depende de C[i-1], no se puede sustituir un bloque cifrado por otro sin que el resultado pase inadvertido. Por desgracia, también tiene sus inconvenientes. 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 desde el punto de vista de la seguridad. Para evitarlo, una práctica habitual consiste en insertar al principio del texto una ristra de datos aleatorios de relleno 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 prestaciones. En el modo ECB, era posible paralelizar el proceso: si necesitamos acceder 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, operando con los bloques de datos de uno en uno. En cuanto a la propagación de errores, existe pero tiene poca trascendencia. Si en modo ECB un error en un bloque cifrado impedía leer un bloque en texto llano, el mismo error en modo CBC afecta solamente a dicho bloque y a un bit del bloque siguiente. Se dice que el modo CBC es autorrecuperativo.

Un problema común a los modos ECB y CBC es el de la 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 o CFB (Cipher-FeedBack), es más complejo, pero elimina los errores de sincronización.

Otra variante, llamada Modo de Retroalimentación de Salida, OFB (Output-FeedBack), es algo más sencilla que la CFB. 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.

—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, 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 ECB, como hemos visto, es vulnerable, los buenos 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, un fabricante poco escrupuloso puede preferir usar el modo ECB por ser el más rápido y simple. El usuario, que no entiende de sutilezas criptográficas, tenderá a valorar más la velocidad de cifrado que la seguridad.

Ocasionalmente, un pretendido experto en seguridad “descubre” las vulnerabilidades del modo ECB con el oculto propósito de anunciar algún producto. Algo así sucedió en octubre de 2008, 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”^[3]. El autor muestra cómo una imagen cifrada en modo ECB permite adivinar contornos de la imagen original. Para ello, toma una fotografía de una chica guapa reducida a cuatro colores: blanco, negro y dos tonos de gris. Al cifrar con el algoritmo AES en modo ECB, se observa cómo algunos de los rasgos de la foto son aún visibles: el contorno de la figura de la chica, su cabello, brazo, cintura. Demasiado detalle para una imagen que supuestamente está bien protegida mediante cifrado.

¿Qué es lo que sucedió? Sencillamente, que al usar cifrado en modo ECB, las zonas de color uniforme se convierten en el mismo tono de “color cifrado”. Cada bloque de datos correspondiente a un solo color queda cifrado de la misma forma; los bloques que incluyan dos colores (por ejemplo, uno que contenga parte de la blusa y parte del pelo) se cifrarán de otra forma. El resultado es una imagen difuminada que todavía puede proporcionar información al ojo.

Es decir, nos están mostrando la obviedad de que bloques iguales de texto llano se convierten en bloques iguales de texto cifrado. Cuando se utiliza un modo ECB combinado con un parámetro dependiente de la posición de cada bit en la foto (algo similar a tomar una clave distinta para cada bloque de datos), la fotografía se convierte en un conjunto de puntos aleatorios sin patrones que podamos visualizar.

¿Por qué publicó este investigador lo evidente? En mi opinión, para asustar. El autor, dando un paso más, afirmaba en su artículo lo siguiente. Imaginemos dos volúmenes cifrados, el original (1) y una copia exacta (2). El volumen 1 se utiliza para guardar la fotografía, en tanto que el volumen 2 no contiene nada. Lo que dice este señor es que podemos “restar” ambos volúmenes (haciendo un XOR entre cada bit del volumen 1 y el bit correspondiente del volumen 2), y al hacerlo aparece el contorno de la fotografía más o menos reconocible.

No es difícil entender 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. De haber creado el volumen 2 independientemente y haberlo dejado vacío, esto no hubiera sido posible, ya que cada volumen tiene un conjunto de datos iniciales llamado vector de inicialización (IV), que precisamente evita este tipo de ataques. Al copiar el volumen tal cual, también copió el IV.

Como pueden ver, el autor está mostrándonos lo que cualquier criptólogo mínimamente competente ya conoce. La información fue recogida en diversas webs especializadas^[4]. Queda preguntarnos por el motivo. Es sencillo: el “artículo” (llamémosle así, aunque no hay constancia de que haya sido publicado nunca) fue, esencialmente, un ejercicio de publicidad enfocado a presentar un problema y, al final de todo, presentar una solución: un programa llamado TurboCrypt. Por cierto, el autor del artículo trabaja para una empresa llamada PMC Ciphers. ¿Se sorprenderán ustedes si les digo que esa misma empresa fabrica y vende TurboCrypt?

La verdad es que todo el tema de PMC y TurboCrypt resulta hilarante. Cuando leí el artículo por primera vez, me sonó un poco raro. Reconozco que me perdí en el artículo, en parte por el rollo de código fuente que incluyen (innecesariamente, creo yo), en parte por la sensación de estar leyendo cómo inventaban la rueda. Decidí hacerle una consulta al criptógrafo y experto en seguridad Schneier, y su respuesta fue tajante: “Sólo están notando patrones cuando alguien cifra en modo ECB. Nada nuevo… y usar ECB es una bobada”. Al día siguiente, publicó el asunto en su blog^[5], 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? TurboCrypt huele profundamente a “aceite de serpiente” (snake oil). Se trata de un divertido término que utilizan los criptólogos para referirse a productos de cifrado que, con palabras rimbombantes y exageradas afirmaciones de robustez, ocultan un interior débil y vulnerable. La expresión proviene del Lejano Oeste, donde ocasionalmente llegaba el típico buhonero en su carreta. A falta de farmacias, el viajante presentaba a los aldeanos su preparado milagroso que curaba todo tipo de dolencias, achaques y enfermedades. Por supuesto, su eficacia era nula, pero para cuando los incautos compradores se daban cuenta nuestro vendedor de aceite de serpiente ya se encontraba muy lejos.

Algo parecido parece suceder con TurboCrypt. Nada más abrir la web correspondiente, nos recibe una pelirroja muy sugerentemente escotada (la misma del artículo) junto con la lapidaria afirmación de “La herramienta definitiva… ninguna agencia gubernamental de este mundo podrá jamás reventar TurboCrypt”^[6]. Hasta aquí, nada que no podamos achacar a un exceso de entusiasmo por parte del equipo de relaciones públicas.

Lo sorprendente viene cuando comenzamos a leer las interioridades 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. El primero es la afirmación de que el cifrado polimórfico era un secreto de estado en Alemania hasta 1999, y que no existe ataque posible contra este tipo de sistemas. A continuación pasan a decir 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”. Según ellos, TurboCrypt puede usarse con AES o con PMC, y la empresa afirma que los usuarios prefieren PMC en un 80% frente a AES; una afirmación tan arrogante como asegurar que el coche que usted quiere venderme resiste cualquier golpe, pero que si lo deseo puedo conformarse con las menores prestaciones de un carro de combate Leopard 2.

En cuanto al algoritmo en sí, no se detallan sus características, pero la información que proporcionan es de lo más extraña: según dicen, el propio algoritmo de cifrado es variable. Se supone que, de entrada, el modo de cifrar está sin definir, y el algoritmo en sí viene determinado por la clave. Según los creadores de PMC, “la suposición clave para un criptoanálisis con éxito es el conocimiento detallado del algoritmo de cifrado… pero el algoritmo del Método Polinómico es DESCONOCIDO”. Si hemos de creer a lo que nos dicen, parte de la clave se utiliza para compilar el código máquina del algoritmo en sí. El resultado final es un flujo de datos pseudoaleatorio, que al sumarlos (xor) con el texto llano nos da el texto cifrado, algo así como lo que hacen los principales algoritmos de cifra en flujo.

Todo esto es, en mi humilde opinión, un sinsentido sin pies ni cabeza tan grande que no sé ni por dónde empezar. En primer lugar, las técnicas de ingeniería inversa permiten obtener el modo de funcionamiento de un algoritmo, aun cuando éste sea secreto. William Friedman consiguió reproducir el funcionamiento de la máquina japonesa de cifrar Púrpura, e incluso consiguió criptoanalizarla sin éxito, a pesar de no haberla visto nunca. El criptoanálisis no se basa en conocer el algoritmo (aunque indudablemente, ayuda), sino en descubrir vulnerabilidades matemáticas, correlaciones no siempre obvias entre texto llano y texto cifrado. Los trabajadores del ramo se basan en los Principios de Kerchhoffs, enunciado en el siglo XIX, uno de los cuales afirma que la seguridad del sistema ha de recaer tan sólo en la clave. Cualquier proceso cuya seguridad se base en mantener detalles del algoritmo en secreto acabará siendo vulnerado.

En segundo lugar, si la clave de entrada es aleatoria, es de suponer que el algoritmo también lo será. Pero precisamente los detalles del algoritmo son clave a la hora de determinar si un sistema de cifra es seguro o no. Cojamos un algoritmo de cifra, como por ejemplo AES, y destripémoslo. Cada permutación, cada tabla, cada inversión, cada proceso están cuidadosamente diseñados para evitar el criptoanálisis. Incluso pequeños cambios, aparentemente inofensivos, pueden dar al traste con la seguridad del algoritmo. Si el diablo está en los detalles, los algoritmos de cifra deben de ser su lugar de vacaciones favorito. Afirmar que un código informático basado en bloques aleatorios produzca la misma seguridad que un algoritmo clásico es como intentar diseñar una ciudad a base de montar piezas de Lego a ciegas.

Incluso si todo ello fuese cierto, el proceso de compilación del código máquina sería lento (y diferente para cada clave) y difícil de asegurar contra mirones. Es posible que las agencias de inteligencia utilicen procedimientos similares, pero de hacerlo les habrá costado mucho esfuerzo, y quedaría por ver qué ventaja les proporcionaría frente a los algoritmos probados conocidos en la actualidad. La industria civil ciertamente no los utiliza, o habríamos visto ejemplos de otras empresas.

Finalmente, las referencias del tipo “hay más claves posibles que átomos en nuestro planeta” sugieren poca seriedad. Una clave de 128 bits o más proporciona seguridad frente a cualquier ataque de fuerza bruta. Si a estas alturas tienen que convencer al usuario de la formidable ventaja de seguridad que obtendrán utilizando claves (de cifrado simétrico) de 1024 bits, deberían mejorar sus técnicas de venta. Que es probablemente lo que hicieron con el artículo de Roellgen anteriormente mencionado.

En la web de TurboCrypt se incluye un desafío criptográfico que le permitirá a usted, lector, ganar diez mil dólares si consigue romper su sistema de cifra^[7]; lleva el atrevido título de "Intente hacerlo mejor que Bruce Schneier. Rompa el Cifrado Polimórfico". A los creadores del desafió no se les escapó el hecho de que Schneier es una especie de Chuck Norris de la seguridad informática, así que publicaron una carta para Schneier, en el que le desafiaban formalmente a atacar su sistema PMC, y tomaron su ausencia de respuesta como una especie de victoria^[8].

Por supuesto, si yo desafiara a Chuck Norris y no obtuviera respuesta, eso no significa que me tenga miedo. Lo más probable es que él tenga mejores cosas que hacer que viajar hasta España para partirme la cara. Algo así pienso que le habrá pasado a Schneier, cuyo único comentario público al respecto fue “tiene gracia”.

Frente a la indiferencia de Schneier, y probablemente en medio de un coro de risas por parte de la comunidad criptográfica, PMC Ciphers llegó a afirmar que la NSA usa su sistema de cifra, así que ha de ser bueno. Llegaron 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 buenos. 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 los fracasos obtenidos por los sistemas de cifra creados bajo los auspicios de la seguridad mediante oscuridad, creo que la afirmación de PMC cae por su propio peso. Los mejores sistemas de cifra han sido siempre los creados a la luz del día, con código abierto y revisable por cualquiera. La única ventaja efectiva de TurboCrypt es esta: representa un buen ejemplo de aceite de serpiente.

2) ACEITE DE SERPIENTE