Cuando la criptografía falla (el libro)

Los que me conocen sabrán que soy un gran aficionado a los temas de criptografía. Es lo que me llevó a Internet, allá por mediados de los noventa, y sólo os daré como ejemplo mi web www.cripto.es para justificarlo. Desde entonces, he escrito mucho sobre el tema.

Como conclusión inevitable, durante el último año le he estado dando vueltas a la idea de escribir un libro sobre criptografía. La pregunta que antes tenía que responderme a mí mismo era ¿por qué? ¿Qué tengo que ofrecer que no se haya escrito ya? Hay muchos libros sobre criptografía, muy buenos algunos. Pero vi que la mayoría de esos libros se limitaban a explicaciones matemáticas prolijas y complicadas. Se trataba de teoría de números aplicada a algoritmos de clave pública, firma digita, funciones hash; todo muy interesante, pero no el tipo de lectura con que nos relajamos frente a una caña de cerveza.

Mi contribución ha sido distinta. Quería hablar de códigos, de algoritmos, de claves; pero sobre todo deseaba enlazarlo con nuestra vida cotidiana. Y es que en este mundo digital moderno, estamos utilizando criptografía constantemente: al conectar el móvil, al sacar dinero del cajero, al navegar por Internet, al enviar mensajes por teléfono, al pagar con el abono de transporte. Incluso su documento de identidad y su pasaporte incluyen elementos criptográficos.

El problema viene cuando la criptografía falla. De repente, y sin motivo aparente, dos y dos dejan de sumar cuatro. En ese instante, sucede algo extraordinario: sistemas matemáticos nítidos y claros, creados por mentes brillantes, de repente se niegan a operar correctamente. El PIN de la tarjeta no nos protege contra clonados, la contraseña WiFi de nuestra casa resulta pan comido para el vecino de arriba y los datos que acabamos de introducir en nuestra red social favorita acaban en el archivo de entrada de otro usuario. Desde los fallos de los algoritmos más sofisticados hasta la estupidez humana, todo conspira para debilitar la seguridad de nuestro mundo digital. A veces se trata de fallos matemáticos muy sutiles; otras veces, sencillamente, el usuario es idiota, o bien la empresa quiere ahorrar en el chocolate del loro. El resultado: otro que muerde el polvo.

Por ejemplo, seguro que usted tiene móvil. ¿Sabe hasta qué punto los algoritmos criptográficos GSM son seguros? ¿Cómo ha evolucionado la protección de las redes de telefonía móvil? ¿Por qué en los años noventa pillaron a Txiqui Benegas hablando de “el enano” o “el one” en su flamante Motorola? ¿Cómo es eso de que los mensajes de WhatApp están mal protegidos? ¿Qué combinación de factores permiten hacer un Scarlett Johannson y robar esas fotos que no debería ver ni tu pareja?

En mi nuevo libro lo explico. La idea es llevar al lector de la mano a través de sistemas que ahora utilizamos habitualmente. En cada caso, los fallos de los sistemas de cifrado que incorporaban fueron causa determinante de su desarrollo posterior. De los DVD hemos pasado al Blu-ray, y en cada paso nos aseguraron que la protección contra copia era total y perfecta. Bien, pásese por cualquier servidor torrent y descubra si tenían razón; luego vuelva al libro para descubrir por qué. Una ventaja con la que cuenta es que he incluido más de quinientas referencias sobre los temas que narro. Si quiere usted acceder a la noticia o el artículo original, nada más fácil que hacer clic en el lugar adecuado. Eso no se puede hacer en un libro en papel, y es uno de los motivos por los que me he centrado en una versión electrónica.

Pero soy el autor y puede que el amor de padre me ciegue. Hay una forma fácil de averiguarlo: entre en Amazon, descárguese el 10% del libro (puede hacerlo, de forma gratuita y sin compromiso) y juzgue usted mismo. Si el veredicto es positivo, espero de corazón que disfrute de la lectura.

He aquí mi obra. Está disponible exclusivamente en formato electrónico, en la plataforma de Amazon. Señoras, señores, niños y niñas, bienvenidos a mi nueva creación:

CUANDO LA CRIPTOGRAFÍA FALLA

Y recuerden el consejo de Sheldon Cooper: 1234 no es una contraseña válida. Feliz Navidad a todos.

PD: Ya me están preguntando eso de "eh, me firmarás el libro, ¿no?" Pues claro que sí. ¿Y qué libro sobre criptografía sería si no pudiese hacerle una firma digital? ¿Queréis que os lo firme? ¡Pues os lo firmo!

Buenas noticias: nos mudamos

Como habréis notado, no me prodigo mucho últimamente en este blog. No, no se me han pasado las ganas de escribir sobre criptografía. De hecho, uno de los motivos por los que escribo tan poco por aquí últimamente es que estoy preparando un libro sobre criptografía. Lo estoy planteando en plan "sí, os voy a explicar cosas, pero vamos a usar ejemplos interesantes para que no os aburráis." De momento lo llamo "Descifrando a Nemo," y ya os iré hablando de él, porque si os interesa la criptografía divulgativa, creo que os va a gustar mucho.

Otro motivo por el que paso poco por aquí es que, sencillamente, el día no es lo bastante largo. otros proyectos muy queridos para mí, relacionados con la divulgación científica, han requerido gran parte de mi atención: Naukas (antigua Amazings.es), el Proyecto de Innovación Docente de mi Universidad, y algunas otras cosillas como comer, ducharme, dormir, debilidades de esas, ya sabéis.

Pero tranquilos, que esto no es una despedida. Ni mucho menos. Tan sólo es una mudanza. Del mismo modo que hice las maletas desde mi web de la Universidad a la actual, ahora vamos a hacer lo propio. La web cripto.es seguirá intacta y con todos sus contenidos. En cuanto al Blog ENIGMA, se fusiona con mi proyecto principal: Física de Película. Los artículos de tema cripto irán allí, donde tendrán una visibilidad mayor y donde me será más fácil gestionar todo lo que me pasa por la cabeza.

Así que ya lo sabéis. A partir de ya, os espero en Física de Película. Para hacer más fácil la separación entre temas, los de índole cripto llevarán la etiqueta Taller de Criptografía. Mañana mismo, lunes, tendréis la primera cripto-entrega, directamente salida de mi próximo libro. Allí me encontraréis. Os espero.

Mamá, me han robado un millón de contraseñas

En los últimos días, hemos tenido noticias de al menos cuatro robos de información en diferentes webs:  Formspring, Yahoo, Androidforums, Billabong y Nvidia.  En todos ellos, los asaltantes tuvieron acceso a la lista de nombres de usuario y contraseñas de un gran número de usuarios (desde 35.000 en el caso de Billabong hasta el millón de Androidforums). En seguida surgen las preguntas: ¿cómo han podido efectuar esos robos?  ¿Por qué los administradores de sistema no han podido evitarlo?  ¿Cómo evitar que suceda?

Da la casualidad de que este verano estoy escribiendo un libro sobre fallos en criptografía.  Tema hay, os lo aseguro.  Mientras escribía el tema sobre contraseñas débiles, estos casos me tuvieron tarumba, no acababa de hablar de uno cuando salía otro.  La ventaja es que, gracias a ello, he aprendido un montón.  Con vuestro permiso (y teniendo en cuenta que apenas tengo el tema en borrador), voy a intentar aclararos el asunto.

¿CÓMO ES POSIBLE QUE OCURRAN ESTOS ROBOS?

Cuando hay un sistema de acceso para múltiples usuarios, como en los casos anteriormente mencionados, la web tiene que guardar los nombres de usuario y la contraseñas en una gran base de datos, un objetivo que por eso resulta muy valioso.  La creencia popular dice que los hackers consiguen acceso a la base de datos, la copian y salen corriendo a estilo Indiana Jones.  Nada más lejos de la realidad.  Lo habitual es realizar técnicas como la llamada "Inyección SQL," que pasa por "inyectar" información que el sistema interpeta como órdenes.  Es algo así como si un guardia de seguridad me interceptase a la puerta de un banco.  El guardia me pregunta por mi nombre, y yo respondo diciendo "mi nombre es 'Arturo Dametucartera' "  El guardia cree que el apellido es una orden ... y me entrega su cartera. Un ejemplo real, tomado de la Wikipedia, nos ayudará a entenderlo.  Tenemos una web que nos pide el nombre de usuario.  El código SQL que usó el programador en la web es:

consulta := "SELECT * FROM usuarios WHERE nombre = '" + nombreUsuario + "';"

En esta consulta, el sistema seleccionará los registros para los que nombre coincida con la entrada del usuario (nombreUsuario).  Si éste teclea la palabra Alicia, la orden que recibe el sistema es:

SELECT * FROM usuarios WHERE nombre = 'Alicia';

Esa orden hará que la base de datos busque todos los registros con nombre Alicia.  Hasta aquí todo normal.  Pero supongamos que el atacante teclea esto:

Alicia'; DROP TABLE usuarios; SELECT * FROM datos WHERE nombre LIKE '%

En ese caso, esto es lo que entenderá el sistema:

SELECT * FROM usuarios WHERE nombre = 'Alicia';

DROP TABLE usuarios;

SELECT * FROM datos WHERE nombre LIKE '%';

Ahora en lugar de una línea de instrucciones, tenemos tres.  Las dos últimas han sido “inyectadas” en el sistema, que ahora hará esto:
- Seleccionar los registros con nombre Alicia
- Borrar la tabla de usuarios
- Seleccionar toda la tabla de datos (que en condiciones normales no debería estar accesible al usuario)


¿CÓMO PODEMOS REMEDIAR EL PROBLEMA?

Una solución al problema de tener un archivo de contraseñas consiste en no tener un archivo de contraseñas.  En su lugar, se guardan los valores hash de las contraseñas. Un hash es una función unidireccional que toma la contraseña C y la convierte en una ristra alfanumérica h=H(C). Una empresa con conciencia de seguridad tomaría todas las contraseñas de los usuarios, sometería cada una a la función hash, y guardaría el resultado.  Cuando el usuario entra una contraseña C, el sistema usa una función hash H y determina su valor para ese caso, digamos h. A continuación, el sistema consulta la base de datos de hashes. Si el correspondiente al usuario coincide con h, eso significa que el usuario ha usado una contraseña válida. De este modo, el sistema ha comprobado la validez de una contraseña sin siquiera saber qué vale. En teoría, un ladrón que se llevase la base de datos de hashes no podría obtener ninguna información sobre las contraseñas, porque conocido h no se puede conocer el valor de C que cumple h=H(C).  Por supuesto, no debe usarse MD5, una función hash muy utilizada en el pasado pero que en la actualidad se considera rota y vulnerable.

Uno de los ejemplos más dramáticos lo tenemos el caso de PlayStation Network. El 20 de abril de 2011, la red de juegos de Sony tuvo que ser desconectada durante casi un mes tras el descubrimiento que los datos personales de sus usuarios habían sido robados.  El número de clientes afectados, más de 77 millones, lo convirtió en uno de los mayores casos sobre robo de información de usuarios. Sony afirmó que las contraseñas estaban protegidas con una función hash, y aunque no dio más detalles el hecho es que, hasta donde yo sé, las contraseñas nunca fueron filtradas públicamente. Por desgracia, Sony no se aplicó su propia medicina en otros casos. En junio de 2011, la web de Sony Pictures fue asaltada por el grupo hacker LulzSec y robó la información privada de más de un millón de personas, incluyendo direcciones de email y contraseñas en texto llano, es decir, sin protección hash alguna.

Aunque el uso de hashes en lugar de contraseñas aumenta la seguridad de un sistema, tiene diversos fallos explotables por un atacante con recursos.  El primero sigue siendo el hecho de que las contraseñas habituales son, como hemos visto antes, sencillas.  Un atacante podría tomar su “diccionario” de contraseñas y aplicar la función hash H a cada una de ellas.  Digamos que la contraseña password tiene con hash la cadena alfanumérica 1c29A, esto es, H(password)=1c24A.  Eso significa que, si en la base de datos de funciones hash que acabamos de robar, aparece un hash igual a 1c24A, ya sabemos que la contraseña correspondiente es password. Hay herramientas informáticas capaces de comprobar miles de hashes por segundo, como el programa John the Ripper, usado habitualmente por los administradores de sistemas para comprobar la fortaleza de las contraseñas de usuario ... y por los hackers para intentar reventarla.

El defensor puede aumentar el nivel de seguridad añadiendo “sal” al sistema.  Como en las aplicaciones culinarias, la sal da sabor al guiso.  En este caso, lo que se denomina “sal” es una pequeña cadena de bits que se añaden a la contraseña.  De este modo, lo que guarda el sistema no es H(password) sino H(password+sal).  Ahora el contrincante lo tiene más difícil, ya que a cada elemento de su diccionario tendrá que añadirle muchos valores de sal hasta encontrar el correcto.

Incluso en el caso de usar funciones hash fuertes y sal, un usuario que utilice una contraseña débil es vulnerable.  Por ejemplo, el 10 de julio de 2012 la red social Formspring reconoció el robo de 420.000 hashes correspondientes a contraseñas de sus usuarios.  La función hash utilizada era la SHA-256, y también empleaban sal, lo que significa que Formspring hizo bien sus deberes (salvo por el detalle de dejarse robar información).  Aun así, el usuario de una contraseña débil está en peligro.  Armados con una lista de contraseñas de uso común, los atacantes no tienen más que probarlas combinándolas con todos los valores posibles de sal para obtener acceso a al menos algunas de las cuentas.  La única defensa eficaz contra una intrusión de este tipo es deshabilitar todas las contraseñas, una medida que requiere valor porque significa molestar a millones de usuarios y enviarles el mensaje de que el sistema es inseguro (Formspring hizo exactamente eso, y hay que aplaudirles por ello); y, en segundo lugar, implementar en el sistema un comprobador que rechace las contraseñas cortas o débiles.


¿CÓMO PROTEGÍAN SUS CONTRASEÑAS LOS ATACADOS?

En los cinco casos que mencioné al principio, hay de todo.  Las técnicas que hemos visto (hash, sal) se deben combinar con una rápida respuesta y un aviso pronto a los usuarios para que cambien las contraseñas.  Si hay que deshabilitar todas las contraseñas y empezar de cero, se hace.

Hay un caso de texto de lo que NO se debe hacer. En diciembre de 2009, un sufrió un ataque cuyo resultado fue el robo de la información (usuario y contraseña en texto llano) de más de 32 millones de usuarios.  Los responsables de RockYou fueron duramente criticados por las circunstancias que se combinaron en ese caso:

- A pesar de que la empresa de seguridad Imperva había avisado del ataque el día 4, la web no advirtió a sus usuarios hasta diez días después
- La cantidad de contraseñas custodiadas en texto llano, sin ningún tipo de protección, era enorme, lo que lo convierte en uno de los mayores robos de contraseñas en texto llano de la historia.
- Las normas de seguridad de RockYou permitían crear contraseñas de tan sólo cinco caracteres, y recomendaba no utilizar “caracteres especiales” (es decir, no alfanuméricos), que en realidad hubieran incrementado la seguridad
- La web de RockYou permitía a sus clientes acceder a sus perfiles de otras redes sociales como Myspace, Hi5, Orkut o Facebook.  Para ello, el cliente introducía las contraseñas de su perfil en dichas redes, y RockYou guardaba una copia.  Sí, ha leído bien: RockYou guardaba contraseñas de otras redes sociales … y lo hacía en texto llano.

Así que vamos a ver cómo se las apañaron nuestro cinco magníficos:

- Androidforums. 1.000.000 contraseñas robadas.  Usaron hash y sal.
- Billabong. 35.000 contraseñas robadas en texto llano.
- Formspring.  420.000 contraseñas robadas.  Usaron hash y sal.
- Nvidia. 390.000 contraseñas robadas.  Usaron hash y sal.
- Yahoo. 450.000 contraseñas robadas en texto llano, sin hash.

Como puede verse, algunas webs atacadas habían hecho sus deberes correctamente (salvo por el detalle de dejarse robar la información).  En el polo opuesto, Billabong y Yahoo la cagaron.  Yahoo se apresuró a arreglar el fallo, que atribuyó a un archivo viejo.  Aun así, el hecho de guardar contraseñas en texto llano le vale un FAIL como una casa.  En cuanto a Billabong, no sólo no ha avisado a sus usuarios sino que ni siquiera ha reconocido todavía el problema, lo que le hace merecedor de un EPIC FAIL.

Pero recordad, usuarios: incluso la mejor protección posible falla si escogéis una contraseña mala.  Huid de contraseñas cortas, fáciles de adivinar (nombres de parientes, fechas de nacimiento, palabras con un "1" al final o con la O sustituyendo a un cero), y os haréis a vosotros mismos un gran favor. En esto, Sheldon Cooper tiene más razón que un santo: 1234 no es una contraseña segura.  Y eso va también por tí, Kal-El, digo Leonard.

Un curso de Criptografía para tí

Gracias a los colegas de Kriptópolis, me acabo de enterar que existe un curso online sobre criptografía.  Vaya novedad, pensaréis. Pero ojo, que este curso tiene solera, porque viene directamente de la Universidad de Stanford.

El profesor es Dan Boneh, del departamento de informática de Stanford.  Ni corto ni perezoso, ha decidido ofrecer un curso sobre criptografía, de modo online y completamente gratis.  La idea es que, cada semana, el profe colgará algunos vídeos explicativos.  Prácticamente es como si estuviésemos allí.  Incluye materiales en formato digital como pdf o mp4.  Cada semana, se pondrán deberes.

No es un curso que nos proporcione créditos docentes, pero es gratis. Lo único que hay que hacer es registrarse.

Eso sí, las clases son en inglés.  Pero para los no curtidos en la lengua de Shakespeare, buenas noticias: los videos tienen subtítulos en inglés y español.  Hay incluso foros de discusión, incluidos unos que se llaman "grupos de estudio," donde los alumnos pueden conocerse y ayudarse unos a otros.  La mayoría son en inglés, pero hay al menos dos en español.  Yo he optado por el "Grupo de Estudios Latino" porque es el que tiene mayor número de inscritos.

Reconozco que no sé si podré seguir el curso correctamente.  Una de las cosas que se necesitan es conocimientos de programación.  Yo sé programar muy bien ... pero en Fortran, un lenguaje muy útil para manejar números pero no muy bueno para los caracteres alfanuméricos.  Pero lo intentaré.  Como mínimo, y aunque no sepa hacer los deberes, aprenderé.  Y disfrutaré en el proceso, que es de lo que se trata.

Si ya estáis deseando intentarlo, he aquí la dirección:

http://www.crypto-class.org/

Nos vemos en el curso.

Las tontas claves de Stratfor y asociados

Como personas modernas y bien informadas que sois, imagino que estaréis al tanto de la última revelación de Wikileaks: varios millones de emails de la empresa Stratfor. Se trata de una empresa dedicada a la recogida y procesado de datos de inteligencia.  Algunos la consideran una CIA privada, aunque oficialmente se dedica a realizar análisis geopolíticos: Nuestro fin es simple, hacer que la complejidad del mundo sea comprensible para un lector inteligente, al margen de ideología, agenda y prejuicios nacionales.

Se supone que una agencia como Stratfor debería mantener una férrea seguridad en sus comunicaciones.  Pero sorpresa, sorpresa, en navidad de 2011 el propio fundador reconoció que su empresa había sufrido una intrusión informática.  Los atacantes consiguieron una lista de miembros y clientes, incluyendo números de tarjetas de crédito y, como se reconoció posteriormente, casi un millón de direcciones de email y contraseñas de acceso. 

Por supuesto, un archivo con las contraseñas de los usuarios es un botín muy jugoso para los atacantes.  ¿Cómo lo protegemos?  Lo mejor es ... no tener un archivo de contraseñas. En su lugar, se guardan los valores hash de las contraseñas.  Las funciones hash, muy útiles en diversos campos de la criptografía, sirven para comparar las contraseñas sin revelarlas. 

Una empresa con conciencia de seguridad hace lo siguiente: toma todas las contraseñas de los usuarios, somete cada una a la función hash, y guarda el resultado.  Cuando el usuario entra una contraseña C, el sistema usa una función hash H y determina su valor para ese caso, digamos h.  A continuación, el sistema consulta la base de datos de hashes.  Si el correspondiente al usuario coincide con h, eso significa que el usuario ha usado una contraseña válida.

Aunque el uso de hashes en lugar de contraseñas aumenta la seguridad de sistema, tiene diversos fallos.  El más gordo sigue siendo el hecho de que las contraseñas habituales son sencillas y predecibles.  Un atacante podría tomar su “diccionario” de contraseñas y aplicar la función hash H a cada una de ellas.

Eso fue lo que sucedió en el caso de Stratfor.  Una de las cosas que se llevaron los asaltantes fue la base de datos con las contraseñas.  Éstas se guardaban en forma de hash (no en texto llano).  Un análisis del diario online The Tech Herald utilizó un conjunto de diccionarios (términos comunes en varios idiomas) y una lista de contraseñas reveladas en anteriores ataques informáticos, y los combinó con el programa hashcat, similar al ya mencionado Jack The Ripper.   

El resultado es demoledor: de los 860.160 hashes que obtuvieron para estudio, consiguieron recuperar casi 82.000 contraseñas en algo menos de cinco horas, usando un sencillo ordenador de trescientos euros.  Algunas contraseñas eran tan absurdas como ****** (seis asteriscos).  Diversos usuarios utilizaron contraseñas lo bastante largas como para proporcionarles seguridad, pero luego lo estropearon escogiendo términos como 111222333444, qwerty123456, lawenforcement, surveillance4u o intelligence.

También se vio cómo algunos usuarios, en un intento por aumentar su seguridad, utilizaban sustituciones de caracteres fácilmente adivinables, como sustituir O por 0, o poner @ en lugar de a. Eso es algo desaconsejado porque proporciona solamente una sensación de seguridad, no más seguridad en sí mismo. Una de las contraseñas de seis caracteres más utilizadas en el caso Stratfor era ¡@#$%^ … que no es más el resultado de pulsar 123456 con el bloqueo de mayúsculas y la tecla AltGr; otras elecciones poco inteligentes incluían $intel, @gn0st!c [agnóstico], @irF0rce [airforce], @tt0rn3y [attorney].  Por supuesto, la cadena de cinco dígitos más utilizada fue nuestra conocida 12345, con 55555 en segundo lugar.

El uso de contraseñas tontas es un tópico tan extendido que forma parte del folklore de Hollywood.  Sheldon Cooper, el protagonista de la la exitosa serie de TV The Big Bang Theory, no encuentra gran dificultad en acceder al ordenador de una tienda de informática: “puede entrar hasta un niño, 1234 no es una contraseña muy segura” En la parodia La Loca Historia de las Galaxias, el planeta Druidia protege su atmósfera mediante un escudo que tiene el código 12345.  Cuando el malvado planeta Spaceballs consigue el código, su presidente no sale de su asombro: “¿12345?  ¡Es la misma contraseña que tengo en mis maletas!”

El presidente Skroob nos parece un tonto redomado, y de hecho fracasó en sus malévolos planes (a pesar de tomar la precaución de cambiar la combinación de sus maletas), pero en nuestro planeta Tierra no lo hacemos mucho mejor.  En febrero de 2012, el grupo Anonymous hackeó la cuenta de correo electrónico del presidente sirio Bashar al-Assad.  Más concretamente, entraron en el servidor de correo del ministro sirio de asuntos presidenciales y accedieron a casi ochenta carpetas de mensajes.  Lo crean o no, la contraseña que custodiaba toda esa información era … 12345.

Seguro que su colaborador, el que creó la contraseña, pensó algo así como "la gente pensará que cualquier idiota la podría en sus maletas, así que nadie creerá que vamos a usarla realmente."  O, por supuesto, es un luser redomado que se merece ser azotado con un látigo LART.  Por cierto, señor presidente sirio, convendría que fuese revisando usted sus maletas.  Por si acaso.

John Nash, un criptógrafo maravilloso

El nombre de John Forbes Nash no le es conocido a mucha gente.  Pero mencionen la película Una Mente Maravillosa, que narra su vida, y verá como la cosa cambia.  Nash fue un genio de las matemáticas.  Especialmente conocidos son sus trabajos sobre la teoría de juegos, que a pesar de su nombre es un campo de estudios muy serio, ya que describe las relaciones humanas, económicas y sociales.  Si algún día alguien desarrolla las matemáticas de la psicohistoria de Asimov, hará bien en comenzar por la obra de Nash.  Precisamente por su trabajo en teoría de juegos, Nash fue galardonado con el premio Nobel de Economía en 1994.

En Una Mente Maravillosa, Nash (interpretado por Russell Crowe) trabaja para la inteligencia norteamericana.  O al menos, eso es lo que él se creía, ya que todo era un producto de su mente: Nash sufría de esquizofrenia. Lo que no sabíamos hasta ahora es que, en su momento, Nash intentó entrar en el campo de la criptografía.  Unas cartas que escribió a la Agencia de Seguridad Nacional norteamericana (NSA) han sido recientemente desclasificadas.  La propia NSA, quizá buscando publicidad, ha abierto una exhibición sobre Nash en su Museo Criptológico.

Nash escribió algunas cartas de motu propio, es decir, nadie le consultó sobre el tema.  La correspondencia data de 1955, algunos años antes de que sus problemas mentales comenzaran a manifestarse.  Aun así, la carta es, digámoslo así, algo rara.  Está escrita a mano, en papel con el membrete del Departamento de Matemáticas del MIT, y pedía que no le tomasen por un "profesor chiflado" sólo porque no estaba mecanografiada.

En principio, Nash se refiere al cifrado mediante una función matemática que dependa de r dígitos binarios y de un conjunto de bits relativos al texto llano.  En principio (afirma, subrayado) un enemigo que conozca r bits cifrados podría calcular la clave.  Eso me parece una afirmación algo atrevida, pero no seré yo quien se atreva a contradecir al genio.  Lo que afirma Nash es que, si el proceso de calcular la clave es demasiado largo, tendríamos un sistema de cifrado seguro a efectos prácticos.

Es decir, Nash está sugiriendo algo que ahora se usa en criptografía de clave pública: usar un problema matemático cuya resolución, aunque posible en la práctica, lleve demasiado tiempo.  Afirma a continuación que se podría clasificar los sistemas de cifrado en virtud de su complejidad matemática, es decir, por cómo aumenta la dificultad de recuperar la clave cuando aumentamos el tamaño de ésta.  Lo ideal sería un sistema cuya resistencia aumentara exponencialmente con la clave.  Un ejemplo podría ser el PIN de una tarjeta de crédito: poner un dígito más aumentaría en diez su resistencia frente a ataques de fuerza bruta.

Nash se atreve a afirmar que, cuando los sistemas de cifrado alcance un nive de complejidad exponencial, el criptoanálisis se convertiría en una cosa del pasado; cosa que él mismo reconoce que no puede demostrar.  Y en este punto es donde la cosa se pone interesante, ya que pasa a decir que:

Creo que la máquina de cifrado y descifrado que he inventado e hice transmitir a la N.S.A. por medio de [la corporación] RAND tiene esta propiedad de "irrompible."

Si eso es cierto, eso significa que hubo contacto previo entre la NSA y Nash, hasta el punto de que éste trabajó en una máquina de cifrado, al menos sobre el papel.  En efecto, la carta de respuesta de la NSA incluye una referencia a una interesante discusión [de algunos técnicos de la NSA] con usted hará cuatro años.  Eso era 1951, el año en que Nash escribía "Non-cooperative games" en la revista Annals of Mathematics, en la cúspide de su carrera.  Como anécdota, hay que decir que Nash incluyó una copia de ese artículo en su carta a la NSA, con objeto de que sirviera de "carta de presentación." La documentación interna de la NSA lo refleja así: El autor también incluyó un interesante panfleto sobre Juegos No-Cooperativos, escrito por el Sr. Nash, para nuestra información.

La descripción del sistema criptográfico de Nash aparece en la documentación que la NSA acaba de hacer público es, a mis ojos, un galimatías.  Eso no significa que sea un mal sistema, sino que yo no lo entiendo.  Para ser más correcto, no sé si el sistema que describe es criptográficamente resistente.  El criptoanalista Ronald Rivest (la R de RSA) recientemente publicó el algoritmo de Nash como ejercicio para sus alumnos.  Si le interesa, aquí tiene una copia en Python.  Según Rivest, es un sistema de flujo (stream cypher).  Si funciona bien, sería muy interesante, ya que es muy difícil hacer un algoritmo de cifrado en flujo que carezca de debilidades.  El propio Rivest, no obstante, advierte a sus alumnos -y a nosotros, de paso- que esta tarea es problema abierto ... ni nosotros mismos sabemos la respuesta a la pregunta.

Por supuesto, la pregunta a que se refiere es: ¿funciona el sistema de Nash?   Porque hay un problema: la NSA lo rechazó.  En una carta al autor, se le informa de que los principios criptográficos de su sistema, aunque ingeniosos, no cumplen los requisitos de seguridad necesarios para aplicaciones oficiales.  En un memorandum interno de la NSA (no enviado a Nash, por supuesto), se detalla algo más sobre el sistema de cifrado de Nash: solamente proporciona una seguridad limitada, y requiere una cantidad de equipo comparativamente grande. El principio no se usaría por sí mismo en su forma actual y se considera improbable que haya modificaciones o extensiones adecuadas, a menos que pudiera ser usado en conjunción con otros principios de auto-clave.  La referencia a auto-clave (auto-key) es un sistema mediante el cual el propio mensaje también hace de clave.

Visto lo visto, y considerando la capacidad intelectual que tenía John Nash, estoy deseando que los criptoanalistas profesionales se pongan a destripar este sistema de cifrado. Si hace casi setenta años Nash ya bosquejaba los inicios de la criptografía basada en la complejidad computacional, quién otras sorpresas nos esperan.  ¿Una mente maravillosa?  Puedes apostar a que sí.

Ojo con la Google Wallet

Si es usted usuario de Google Wallet, cuidado, su dinero puede estar en peligro.  Ah, te has dado cuenta tú también ...

Recientemente, Google ha inventado una aplicación llamada Google Wallet para poder controlar los pagos por medio del móvil.  Google Wallet está diseñado para ser utilizado con los móviles que tengan capacidad NFC.  Eso significa Near Field Communications, y es una actualización del sistema RFID que tan criticado fue en el pasado.  La idea es convertir el móvil en una especie de tarjeta de crédito.  De conseguirlo, darían un paso de gigante, ya que ahora la gente usa el móvil para todo, y podría incluso permitirles entrar en el campo de los micropagos.

Pero claro, hay que hacer las cosas bien y con cuidado.  La tecnología NFC permite a un atacante espiar los datos del usuario, así que hay que meter cripto en el asunto.  La información sensible como el número de tarjeta de crédito es almacenada de manera cifrada en un elemento llamado SE (Secure Element), protegido contra todo tipo de espionaje electrónico, y el acceso al SE está fuertemente controlado.  Para poder acceder al SE, el sistema Google Wallet pide al usuario un número PIN de cuatro dígitos, y aunque un ladrón se llevase nuestro móvil del bolsillo, necesitaría ese PIN para poder darse un atracón de chuletones a nuestra costa.

Un análisis realizado en diciembre por viaforensics.com muestra un nivel de seguridad elevado.  Intentaron un ataque de intermediario (MITM, Man In The Middle), sin éxito. Tampoco consiguieron obtener información importante del propio móvil.  Pero Android es un sistema operativo basado en Linux, y como tal es posible obtener acceso de administrador ("root access"); no es algo que las operadoras hagan de forma habitual, pero un usuario con conocimientos podría obtenerlo, por ejemplo, para hurgar en las tripas de su móvil, configurarlo de forma especial o instalar ciertos programas.

Cuando los investigadores "rootearon" el móvil, inmediatamente comenzaron a recuperar información sobre las transacciones efectuadas: fecha, nombre del usuario, límite de crédito, tipo de tarjeta de crédito vinculada, etc.  No consiguieron información sensible, como el número de cuenta corriente, el de la tarjeta o el PIN (que se guarda en la SE, es decir, fuera del acceso normal), así que de momento todo va bien.  

Pero otros grupos se envalentonaron y comenzaron sus propios análisis.  Uno de ello, de la web zvelo.com, puso los pelos de punta.  Consiguieron recuperar el PIN.

Para ser justos con Google, hay que reconocer que lo intentaron hacer bien.  En lugar de guardar el PIN en el móvil, lo que hicieron fue lo siguiente: el usuario teclea el PIN, Google Wallet lo pasa por una función hash, y el resultado se compara con otro valor hash guardado en Wallet.  La función hash usada era la robusta SHA256, y usaron el truco de "sal" (una pequeña cadena de datos que se une al PIN antes de someterlo a la acción del hash); es decir, hicieron bien sus deberes.

El problema es que el PIN tiene cuatro dígitos solamente, es decir, solamente hay 10.000 posibles valores del PIN ... y 10.000 posibles valores de hash.  Los investigadores encontraron el valor de la "sal" y se limitaron a probar los 10.000 posibles valores de hash(PIN+sal), uno para cada valor del PIN.  De ese modo, cuando encuentran un PIN "hasheado" en Google Wallet, ya saben a qué PIN pertenece.

Google Wallet permite solamente cinco intentos de introducción de PIN; al quinto fallo, el sistema se bloquea.  Pero el ataque zvelo.com no necesita ir probando, ya que basta con leer el hash y determinar a qué PIN corresponde.  Nuevamente, este ataque requiere acceso root.  Incluso los usuarios que no juegan con sus móviles (no al juego de destriparlos, quiero decir) podrían estar en peligro, si alguien le "pide prestado" su móvil y le abre acceso root.

Sorprendentemente, parece que Google se lo ha tomado de forma muy responsable.  Y digo sorprendentemente, porque lo habitual en estos casos es que la empresa perjudicada se haga el sueco, niegue la mayor y/o amenace con demandas judiciales.  No parece haber sido el caso.  Google ha tomado muy buena nota de ello, y mientras prepara sus actualizaciones ha emitido un comunicado en el que reconoce y describe el problema. La respuesta podría pasar por almacenar la información vital (PIN y sal) en la propia SE, así como impedir o hacer más difícil el acceso root.

Cualquier solución tendrá sus problemas.  En primer lugar, evitar acceso root no será nada fácil, sobre todo si tenemos en cuenta que los móviles que ahora llevan Wallet son el Galaxy Nexus y Nexus S, que se venden como "móviles de desarrolladores," esto es, gente con conocimientos técnicos altos, mucha curiosidad y ganas de comprobar hasta dónde puede llegar su móvil.  Un segundo problema es el legal: si Google impone una solución técnica al sistema, los bancos pueden declinar la responsabilidad en el caso de que algo salga mal.

Para mayor desesperación de Google, pronto se desveló un segundo ataque.  Es tan estúpido que apenas se le puede llamar hacking.  El problema es que Google Wallet está ligado al móvil, no a la cuenta de Google, así que cuando el ladrón.  Digamos que un ladrón le ha robado su móvil, lector.  Lo único que tiene que hacer es entrar en Ajustes y borrar los datos de la aplicación Google Wallet. A continuación, abre Google Wallet.  Como el PIN estaba guardado en los datos borrados, la aplicación actuará como si estuviese recién instalada, así que ¡le pedirá un nuevo PIN!  Sí, así es: borre los datos de Wallet y ábrala, el sistema le pedirá un nuevo PIN, usted mete el que más le guste, y voilá.  Como los datos de la cuenta corriente y la tarjeta de crédito estaban en el SE, no han sido borrados.  A comprarse el Bugatti Veyron se ha dicho, que paga la víctima.  Y lo peor de todo es que no necesita acceso root.

En estos momentos, más de un ingeniero de Google está sudando la gota gorda intentando resolver el problema.  Lo conseguirán o no, eso ya lo veremos.  Pero, como mínimo, hemos de aplaudir el comportamiento de Google.  No es tan común ver a una gran empresa agachar la cabeza y reconocer "sí, es cierto, la cagamos, lo siento, estamos arreglándolo, aquí tienen mi número si tienen algún problema."  Mientras tanto, si usted es usuario de Google Wallet ... no lo rootee, por la cuenta que le trae.