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.

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.

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.

No hay perdón para Alan Turing

Después de sesenta años, el criptoanalista Alan Turing sigue condenado por indecencia mayor.  Una petición popular de indulto ha sido recientemente rechazada por el gobierno británico.

Seguro que cualquiera que haya estudiado informática habrá oído hablar de Alan Turing.  Quizán no sepan de la vida y milagros de este talento matemático, pero seguro que conocen el test de Turing y la máquina de Turing.  Puede que algunos pocos sepan de su papel como criptoanalista durante la Segunda Guerra Mundial.  Y muy pocos sabrán en qué circunstancias halló la muerte.

Alan Matheson Turing nació en 1912.  Su talento para las matemáticas le permitió graduarse con honores en el King´s College de Londres.  Pronto se centró en el conocido como "problema de decisión" (Entscheidungsproblem).  Propuesto por el matemático David Hilbert en 1928, este problema consistía en determinar si existe un algoritmo, o cadena de pasos lógicos, que permita determinar si una afirmación es verdadera o falsa; dicho de otro modo.  Turing atacó el problema imaginando una máquina calculadora capaz de resolver cualquier problema matemático.  Por medio del concepto de máquina (universal) de Turing consiguió demostrar que la respuesta es negativa.  No hay máquinas capaces de resolver cualquier problema, y no hay forma de demostrar todas las afirmaciones.   Algunas preguntas no tienen respuesta posible.

Turing intentó imaginar cómo podría ser su máquina conceptual, pero la Segunda Guerra Mundial le obligó a posponer su trabajo en ordenadores.  Su capacidad matemática le llevó a la Government Code & Cipher School (GC&CS), una instalación secreta del gobierno ubicada en Bletchley Park y pensada para romper los códigos secretos alemanes.  Junto a Dilly Knox, comenzó a trabajar en el problema de la máquina Enigma usada por las fuerzas armadas alemanas.  En aquellos tiempos, el grupo de criptoanalistas polacos de Marian Rejewski ya había dominado ese tema, pero los ingleses todavía no lo sabían, y el "Tratado de Turing sobre la Enigma" (conocido como "el libro del Profe") fue el "manual" no oficial sobre cómo destripar los códigos Enigma.

Los logros de Alan Turing en el campo del criptoanálisis son enormes, y nos llevaría mucho tiempo detallarlos.  Baste decir que su trabajo fue de enorme importancia.  Desarrolló un invento llamado "bomba," un dispositivo mecánico que permitía obtener las claves Enigma, y dedujo el complicado sistema de indicadores para ajustar la Enigma naval, mucho más difícil que la militar.  Incluso en un lugar tan lleno de talento como Bletchley Park, Turing destacada sobre los demás.  Era un gigante entre los grandes.  La importancia que tenía en aquellos momentos el centro de descifrado queda ejemplarizada con una conocida anécdota.  En octubre de 1941, hartos de trabas burocráticas, Turing y otros tres criptoanalistas (Welchman, Alexander y Milner-Barry) puentearon los canales oficiales y enviaron una carta al primer ministro contándole los problemas que estaban teniendo.  Churchill, que tenía en alta estima a sus "gansos que ponían huevos de oro y nunca cacareaban," tomó cartas en el asunto, y en un memorándum a su asesor militar dictó una famosa Orden del Día:

Asegúrese de que tengan todo lo que quieran, con prioridad extrema, e infórmeme de que se haya hecho así

... y me permito recordar al lector que, con una guerra en múltiples frentes y la propia supervivencia del país en juego, "prioridad extrema" son palabras mayores.

Terminada la guerra, Turing se dedicó al diseño del que sería su "maquina Universal" hecha realidad, el ACE (Automatic Computing Engine). Entre sus muchos logros, encuentro en la Wikipedia que fue él quien desarrolló un método de resolución de matrices denominado "descomposición LU," y que yo utilizo en mi trabajo de simulación científica (Moe, código fuente).

Pero todos los logros de Turing fueron inútiles para ayudarle en lo que se le venía encima.  Resulta que era homosexual, y eso no solamente lo convertía en un peligro de seguridad (por los riesgos de chantaje) sino que además era ilegal.  Los superiores de Turing durante la guerra, o no sabían de su condición, o miraron para otro lado.  Pero en 1952, la cosa cambió.  En enero, la casa de Turing fue asaltada, y el ladrón resultó ser un amigo Alan Murray, que vivía con Turing.  Éste fue a dar parte del robo a la policía, y casi sin darle importancia reconoció que tenía una aventura con el tal Murra.  Tal como relata Stephen Budiansky en Battle of Wits, "buscar ladrones era un trabajo duro, pero procesar a gente que entra en la comisaría de policía y ofrece una confesión era fácil.

¿Y qué delito había cometido Alan Turing?  Indecencia mayor, un delito reflejado en la ley penal de entonces.  No importaba que fuese una ley de la era victoriana (1885, nada menos).  En lugar de molestarse en buscar al ladrón, Turing se convirtió en la víctima.  El gobierno británico tardó poco en retirarle la acreditación de seguridad, en un movimiento que recuerda vagamente al de Oppenheimer, el padre de la bomba atómica, apartado de su cargo tras la guerra por pretendidas simpatías comunistas.  Turing fue retirado de su trabajo con ordenadores, se le prohibió continuar sus labores de consultoría con el GCHQ (Government Communications HeadQuarters, sucesor del GC&CS), y solamente se libró de una condena de dos años de cárcel a cambio de someterse a una terapia hormonal (un modo de castración química, en realidad).  Tras dos años de profunda depresión, el 7 de junio de 1954 mordió una manzana impregnada en cianuro y se suicidó.  Tenía cuarenta y dos años.

El hombre que en 1999 fue escogido por la revista Time como una de las cien personas más importantes del siglo XX hizo una contribución invalorable al esfuerzo de guerra aliado.  Su nombre es mítico en el mundo de la informática, y 2012 ha sido declarado Año de Alan Turing en Inglaterra.  Incluso le acaban de dedicar un sello de correos.  Pero, a pesar de ello, sigue pesando sobre él la losa de esa condena por "indecencia mayor."  El 10 de septiembre de 2009, tras una campaña pública, el primer ministro Gordon Brown realizó una declaración de disculpa:

"Su tratamiento fue, por supuesto, de lo más injusto, y me alegro de tener esta oportunidad para decir lo profundamente que lamento lo que le ocurrió ... Es gracias a ... gente como Alan Turing que los horrores del Holocausto y de la guerra total son parte de la historia de Europa, y no de su presente. En nombre del gobierno británico, y de todos aquellos que viven libres gracias al trabajo de Alan, me siento orgulloso de decir: lo sentimos, se merecía usted algo mejor"

Pero a pesar de ello, mucha gente consideraba que Alan Turing debía ser reivindicado de forma más formal, mediante un indulto póstumo.  Parece lo mismo, pero hay matices importantes.  Una disculpa (apology) era una forma de decir "perdón, le tratamos mal," y un indulto (pardon) es algo así como "usted no hizo nada malo."  Cuando la disculpa de Gordon Brown, hubo quien pensó que había que pedir disculpas a Turing por lo mal que lo trataron, pero que realmente se le condenó por una ley vigente en su epoca.

Y así acaba de suceder.  Una reciente petición de indulto admitida a trámite en la Cámara de los Lores acaba de ser rechazada por el gobierno británico.  Los motivos aducidos por el ministro de Estado son estos:

"No se consideró un indulto póstumo, ya que Alan Turing fue condenado por lo que en aquel tiempo era una ofensa penal.  Debía haber sabido que su delito era contra la ley y que sería procesado.  Es trágico que Alan Turing fuera condenado por un delito que ahora parece tanto cruel como absurdo, particularmente si tenemos en cuenta su sobresaliente contribución al esfuerzo de guerra.  Sin embargo, la ley de aquellos tiempos exigía un procesamiento, y la política al respecto ha sido siempre aceptar que tales condenas tuvieron lugar, en lugar de intentar alterar el contexto histórico"

Lo triste del asunto es que, técnicamente, el señor Lord tiene razón.  Turing fue juzgado y condenado por leyes vigentes en aquel momento.  Pero según ese razonamiento, también deberíamos aceptar la validez el Holocausto judío porque era legal según las leyes alemanas de la época.  Todavía tenemos los españoles el sambenito de bárbaros incivilizados por la herencia de la Inquisición ... que también actuó legalmente en su momento.  Que una ley sea legítima no la hace necesariamente justa.

¿Revisionismo histórico?  No, señores.  Justicia.  Pura y simple justicia.

Los criptógrafos de ETA

La semana pasada, el Ministerio del Interior nos informaba sobre la detención en Francia de Iraitz Gelasaga Fernández, en el marco de la llamada Operación Linux.  Lo relevante para nuestro blog es que Gelasaga es considerado el experto en informática y encriptación de ETA.

Es noticia, pero realmente no es nuevo. Y es que los terroristas no son tontos, y si Internet está a su disposición para comunicarse, no van a hacerlo en texto llano.  El uso de cifrado por parte de la banda terrorista se remonta, al menos, a finales de los 90.  Nacho García Mostazo, en su libro Libertad Vigilada, lo contaba así:

Desde finales del año 2001, agentes de la Oficina Federal de Investigación (FBI) de Estados Unidos empezaron a colaborar con la Policía española para descifrar la información contenida en los ordenadores intervenidos a ETA, según confirmaron fuentes de la lucha antiterrorista a la agencia Europa Press. Según las mismas fuentes, esta cooperación es fruto de los acuerdos suscritos entre Washington y Madrid tras los atentados del 11 de septiembre. Una de las peticiones de colaboración en la que insistieron especialmente las autoridades españolas fue la de compartir tecnologías que sirvieran, sobre todo, para poder descifrar la información de los ordenadores incautados a ETA. Al parecer, la dificultad para romper la clave que los protege obstaculiza la lucha antiterrorista. Por eso España tenía gran interés en contar con tecnología y expertos que contribuyeran a descifrar la información cifrada en soportes informáticos, y además, con la premura requerida para que los datos se mantuvieran vigentes y, por lo tanto, útiles para la investigación (Todo el capitulo aquí).

A finales de 2001, George Bush ponía a disposición de Aznar los medios técnicos de EEUU en la lucha contra ETA.  Se dijeron muchas tonterías sobre la red Echelon y el uso de satélites, a estilo 007, pero la verdadera ayuda estaba en la obtención de tecnología más mundana pero altamente eficaz, como material de cifrado o medios para pinchar móviles.  Y me refiero a antes del 11-S.  De hecho, yo publiqué  un artículo al respecto el 5 de Septiembre.

Eso hizo que ETA reaccionase protegiendo sus comunicaciones, y que las fuerzas de seguridad del Estado intensificasen su preparación en criptoanálisis.  Desafortunadamente, dicen que la verdad es la primera víctima de la guerra.  Quiero con ello decir que el uso de criptografía por parte de los terroristas vino a teñir esa herramienta de un halo malévolo.  Cuando la cripto se usa para proteger nuestros datos, parece que es buena; pero luego llegan los malos y la usan.  ¿Conclusión?  Hay que restringirla, o cuando menos, dar la impresión de que es un instrumento del mal.

En 2008, el etarra Txeroki era detenido por la policía francesa. Entre otras noticias, se hizo público que utilizaba el programa de cifrado PGP para proteger la información.  Oscar de Otálora, un periodista, escribió en el Diario Vasco un artículo lleno de despropósitos sobre la relación entre ETA y PGP.  Pueden leer su artículo, y después contrastarlo con mi contestación que le envié al día siguiente, y de la que nunca obtuve respuesta (tampoco la esperaba).

De hecho, resultaría raro que la banda terrorista NO utilizase PGP, ya que se trata de un programa de eficacia probada y que se usa desde hace veinte años (si les interesa su historia, pueden comenzar por aquí).  Venir en pleno 2008 a asombrarse porque ETA utiliza PGP es como escandalizarse porque un etarra se ha comprado un Seat León.

Sin embargo, las fuerzas policiales siguieron dando palos al entramado etarra, incluyendo sus comunicaciones.  El hecho de que consideren la información digital como tema prioritario puede verse claro cada vez que se hace una redada: además de las armas y municiones, casi siempre nos cuentan que se ha incautado "material informático", que por supuesto es analizado hasta el último bit.

Quizá a algunos les sorprenda que, incluso usando PGP, las fuerzas de seguridad consigan éxitos contra las comunicaciones etarras.  Los expertos saben bien que el mejor sistema de seguridad es inútil si se utiliza mal.  No voy a darles demasiadas pistas, pero uno de los ataques criptográficos más eficaces pasa por intentar averiguar la clave.  En ocasiones, las partes no usadas del disco duro albergan información sobre dicha clave.  Otras veces, sencillamente, es que -parafraseando mal a House- el usuario es idiota.  No encuentro otra explicación ante este artículo de Enero de 2009. Resulta que la clave privada que usa PGP ha de ser protegida mediante una contraseña.  Cuanto más difícil sea la contraseña de adivinar, peor lo tendrá un atacante.  Pues fíjense cómo recomienda ETA a sus miembros que escojan la contraseña:

Según las fuentes consultadas por ECD, los etarras eligen para sus contraseñas privadas oraciones, eslóganes o consignas, casi todo en euskera antiguo. Incluso escogen estrofas de canciones, también en euskera.

!Qué listos!  Seguro que a la Guardia Civil jamás se le hubiera ocurrido.

En cualquier caso, hay que recordar que PGP fue diseñado para proteger el correo electrónico.  Si te cogen el ordenador, la información suele estar "en claro", esto es, no cifrada.  Sería preciso usar un programa que cifrase todo el disco duro.  Y eso es lo que hicieron los etarras.  Para ello, decidieron usar TrueCrypt, un programa de cifrado integral que, bien usado, protege todo el contenido del disco duro de un ordenador.  Es el programa que recomendaría yo mismo para proteger un ordenador.  De hecho, se lo instalé a un cliente que tenía sospechas de espionaje por parte de un organismo estatal llamado [lo siento, no daré detalles].

Es tan sólo una hipótesis por mi parte (la nota de prensa no da detalles), pero supongo que lo que hacía el "experto en informática y encriptación" Iraitz Gelasaga Fernández era, sencillamente, instalar TrueCrypt en los ordenadores y luego enseñar a los demás cómo usarlo.  Aunque, si el etarra medio sigue usando contraseñas como Patxi123, no creo que les sirva de mucho.

APÉNDICE: ¿a usted le molestó que la policía denominase al operativo Operación Linux?  No es el único.  De hecho, se han reído de nosotros hasta en Inglaterra.  El propio Ministerio de Interior ha tenido que pedir disculpas en una nota de prensa.  Aunque no explican el motivo por el que se les ocurrió utilizar ese nombre, al menos piden disculpas por la metedura de pata.  Afirman asimismo que ellos mismos son usuarios habituales de Linux.  Por mi parte, disculpas aceptadas.  Pero como a la próxima redada la llamen Operación Apple, que se preparen para el chaparrón.

Censurando los ataques a tarjetas con chip

El uso de chips en tarjetas de crédito está creciendo como la espuma en los últimos tiempos.  La industria nos lo vende como un método más seguro, y ciertamente parece más difícil adivinar un PIN que leer una banda magnética.  Resulta curioso cómo les ha entrado a los bancos la prisa para colocarnos estas nuevas tarjetas.  Yo ya había oído en 2002 hablar a técnicos del BBVA sobre este sistema, y de cómo iban a implantarlo de hoy a mañana.  Por fin, se ha  decidido.Y ahora, yo mismo tengo dos tarjetas con chip en el cajón.  Me las ha enviado mi banco, sin yo pedirlas, un año antes de que las antiguas caduquen.  En el Mercadona de mi barrio, siempre que pueden, usan el chip antes que la banda magnética.

Resulta conmovedor lo que nos quieren los bancos.  Siempre pensando en nuestra seguridad.  Por supuesto, reducir el fraude también les beneficia a ellos. Pero hay un pequeño detalle que nos cuentan.  Resulta que la responsabilidad por un uso fraudulento o incorrecto de una tarjeta bancaria varía según el método utilizado.  Si usamos la banda magnética y firmamos el recibo, se supone que lo hemos hecho todo correctamente, y si hay algún problema, la culpa se achaca al vendedor o al banco emisor de la tarjeta.  Sin embargo, se supone que el PIN del chip es personal e intransferible, así que en caso de fraude el bando supone que el responsable del mal uso es el usuario.  De ese modo, transfieren la responsabilidad al usuario, quien se las verá canutas para demostrar que no le dejó a nadie su PIN.

En el contrato con mi banco, por ejemplo, hay una cláusula que dice que será mi responsabilidad custodiar en secreto mis elementos de seguridad identifativos (PIN).  Si alguien me los copia, deberé comunicarlo sin tardanza.  De otro modo, lo que compre el ladrón a mi nombre lo tendré que pagar yo.  Aunque una sentencia del Tribunal Supremo lo considera práctica abusiva y por tanto nula, tengo mis dudas sobre sus efectos.

Todo esto no debería ser problema si el sistema de chip fuese realmente seguro.  Pero resulta que no lo es.  En Febrero de 2010, un grupo de investigadores de la Universidad de Cambridbe encontró una forma de solventar la seguridad del sistema.  El problema surge porque los sistemas de chip y de banda magnética deben coexistir.  En ciertas circunstancias, un intermediario malicioso puede introducirse en el sistema par que la tarjeta no verifique el PIN introducido, y al mismo tiempo engaña al terminal (el tarjetero de un restaurante, por ejemplo) para que se crea que el PIN es válido. El ataque, que yo denominé "Fish ´n chips" (ver el Boletín Enigma 74), se basa en una vulnerabilidad conocida desde al menos 1999, y no es sólo un ejercicio teórico sobre el papel.  Según los investigadores de Cambridge,  "contactan con nosotros, de forma regular, clientes bancarios que sufrieron transacciones fraudulentas poco después de que les robaran la tarjeta, que declaran que no escribieron en ninguna parte su PIN, pero que a pesar de eso el banco les acusa de negligencia y rehúsa cubrir las pérdidas. El ataque que describimos aquí puede explicar algunos de esos casos"

Ahora la industria bancaria da un nuevo giro de tuerca.  En lugar de reconocer el problema o intentar arreglarlo, intenta acallar a los mensajeros.  La víctima ahora es Omar Choudary.  De origen rumano (y madrileño de nacimiento), en la actualidad es doctorando en la Universidad de Cambridge, y trabaja en temas de autenticación y seguridad en móviles.  Una de las cosas que Choudary ha hecho es construir un aparato llamado "SmartCard Detective", diseñado para demostrar la vulnerabilidad antes mencionada en los sistemas EMV (se llama así al protocolo que utilizan las tarjetas con chip) y, más importante, para prevenirla.  Es un módulo de seguridad adicional.  El SmartCard Detective es su trabajo para obtener el título de Master of Philosophy.

Resulta que dicho trabajo (que pueden consultar aquí) ha irritado a la industria más de la cuenta.  La UK Cards Association (UKCA) envió el pasado 1 de Diciembre una nota a la Universidad de Cambridge, en la que afirman que la publicación de esa tesis sobrepasa las fronteras de la "revelación responsable", y piden que la investigación de Choudary "sea retirada del acceso público inmediatamente".  Los motivos son los de siempre en estos casos: los malos podrán usar esos conocimientos para perpetrar fraudes.  Como si no lo supiesen a estas alturas.

Cualquier universidad española se hubiera arrugado de inmediato y les hubiera puesto la cabeza del investigador en bandeja de plata.  No así Cambridge. Ross Anderson, investigador en Cambridge, co-tutor de Choudary y una autoridad mundialmente reconocida en el campo de la criptografía (además de ser co-autor del artículo de Febrero de 2010), les puso las peras a cuarto en una carta escrita el día de Nochebuena.  Negó que se hubiese revelado información nueva y rechazó las acusaciones de la UKCA.  Ante la acusación de que estaban minando la confianza del público, replicó:

"Lo que dará confianza del público a esos pagos es la prueba de que los bancos son francos y honestos al admitir sus debilidades, y diligentes al poner los remedios necesarios.  Su carta muestra que, por el contrario, sus bancos miembros hacen lamentables esfuerzos por denigrar el trabajo de los que se encuentran fuera de su club, y de hecho los censuran."

También, con cierto deje de sarcasmo, escribe: "Me alegro de constatar en su carta que el ataque ya no funciona, y alegre de que la industria haya conseguido tratar por fin con este problema de seguridad, aunque se tomaron su tiempo tras la revelación original allá por 2009"

Y añade con esta andanada, que creo vale la pena resaltar:

"Ustedes parecen creer que nosotros podríamos censurar una tesis que es legal y ya en dominio público, tan sólo porque un poderoso interés lo encuentra inconveniente.  Esto muestra una profunda incomprensión hacia lo que hacen las universidades y cómo trabajamos.  Cambridge es la Universidad de Erasmus, de Newton y de Darwin; censurar escritos que ofenden a los poderosos es de lo más ofensivo contra nuestros valores.  Aunque la decisión de poner la tesis online fue de Omar, no tenemos otra alternativa que la de respaldarle.  !Esto sería así aunque no estuviésemos de acuerdo con el material [de la tesis]!.  Por consiguiente, he autorizado que la tesis sea reproducida como Informe Técnico del Laboratorio Informático.  De esa forma será más fácil de encontrar y citar, y asegurará su presencia permanente en nuestra web" 

Aquí me temo que la cosa no pasaría de una nota de prensa, una Universidad atemorizada y un investigador amordazado.  Como profesor universitario, debo declarar que ojalá tuviésemos aquí ese coraje e independencia. !Qué envidia!

En cuanto a la UKCA, ya en Febrero de 2010 publicaron un comunicado en el que negaban la mayor: el sistema Chip+PIN es estupendo, no hay pruebas de que se esté usando en la práctica, lo estamos haciendo muy bien, gracias por llamar.  En lo que respecta a su intento de censura, guardan silencio.  Hasta el momento de escribir estas líneas, la última palabra la tiene Cambridge.  En el Light Blue Torchpaper (el weblog del grupo de seguridad de laboratorio informático de Cambridge), un artículo titulado Feliz Navidad a todos los banqueros, el propio Ross Anderson afirma que presentarán los resultados en la conferencia Financial Cryptography de 2011, el próximo 2 de Marzo.

Al menos, hay un consuelo.  El banco Barclays Bank ya ha arreglado esta vulnerabilidad.  Lo que demuestra que, si hay ganas, el problema se arregla.  Por lo menos, en el banco Barclays de Inglaterra.  Mientras no llegue aquí la solución, creo que mis relucientes tarjetas nuevas se van a quedar en el cajón una temporada.