Boletín ENIGMA - nº 76

1 de Mayo de 2010

 


Boletín del Taller de Criptografía de Arturo Quirantes Sierra


Dirección original: http://www.cripto.es/enigma/boletin_enigma_76.htm


EDITORIAL

TEMAS DE ACTUALIDAD - Cuando las claves no aparecen: el caso Childs

TEMAS DE ACTUALIDAD - Reventando A5/1RES

TEMAS DE ACTUALIDAD - A corazón abierto III: tus claves donde yo pueda verlas
 


 

 EDITORIAL

 

Llevo una temporada que no sé qué me pasa. Comienza el mes, y pienso que voy a tener tiempo de sobra para escribir mi boletín. Siguen pasando los días, y me aplico eso del "voy a escribir algo, pero hoy no ... !mañana!". Y el mañana llega, y luego pasa otro, y otro. Al final, me disciplino y me empieza a salir un pedazo de artículo. Un descanso, y otro día sigo con la faena, luego me quedo bloqueado, encuentro otro tema, me lanzo, sigo, !y ya está! Y, de repente, se me olvida lo que quería escribir en el editorial, de modo que en plan resaca pongo lo primero que se me ocurre, como por ejemplo la historia de cómo siempre dejo el editorial mal hecho.

Pero aquí estyo, por septuagésima sexta vez desde que se me ocurrió meterme en este jaleo. Este mes tenemos una actualización sobre el asunto de los marcapasos criptográficos, otro sobre la telefonía GSM y un ejemplo de lo que pasa cuando alguien decide guardarse las claves en el bolsillo y no compartirlas con los demás niños.

Este mes tengo noticias especiales. En primer lugar, recordaréis que en el boletín del mes pasado escribí un artículo titulado "mis plagiadores favoritos", en el que comenté cómo una empresa está fusilando mis textos desde hace una década, y vendiéndolos a buen precio en un curso de comercio electrónico. No ha habido arreglo posible (más bien, han pasado de mí como si yo fuese tonto), de modo que finalmente he interpuesto una querella contra ellos. Lo más sorprendente es la rapidez con la que se está desarrollando todo. La querella se interpuso un jueves, !y el lunes siguiente ya estaba abriendo diligencias previas! Por cierto, para quien tenga curiosidad le diré que la empresa en cuestión se llama ESINE. Curiosamente, el Curso sobre Internet y Comercio Electrónico, donde me consta que aparecían mis contenidos, ya ha desaparecido de su web. !Ah, pillines!

En otro orden de cosas, tengo que anunciaros el último proyecto de José Ramón Soler Fuensanta, compañero de fatigas criptográficas, criptocontagiado, competidor y además amigo. Su infección de Criptobacillus ha empeorado, y su último síntoma se llama "Criptohistoria" (http://www.criptohistoria.es). Los aficionados al tema encontraremos estupendo material (en calidad y cantidad), resultado de sus años de afición al tema. Considerando que J.R. ha escrito artículos e incluso libros sobre el tema, ya podéis poneros el babero, porque os váis a poner las botas. El esfuerzo ha merecido la pena (juzgad vosotros mismos), aunque su autor me reconoce que "tenías razón, es un trabajo de narices, si lo sé no me meto". Peor para él. !Y mejor para todos nosotros!

Finalmente, el cierre "yo, yo y mil veces yo." El viernes 30 de Mayo, justo cuando hayáis recibido este Boletín, el que firma aparecerá en la tele. Concretamente, en uno de los más novedosos formatos de Cuatro, REC, dirigido por Jon Sistiaga. El programa se titula "¿Estamos desnudos en Internet?", y aborda diversos aspectos de nuestra vida digital, desde el phishing y las mafias de los troyanos hasta sistemas como Sitel, pasando por los ciberdelitos, el hacking (creo que es la primera vez que se saltan los tópicos) y muchas cosas más que se quedaron fuera por falta de tiempo. No me hago responsable de la introducción que me hace Laura Gimeno (suena como si yo fuese el heredero de Turing en España), pero como no tengo abuela, por mí vale.

El programa se emite en Cuatro, sobre las 23:30 de la noche. Si no podéis aguantar hasta esa hora, os recomiendo una tila y el avance del programa en http://www.cuatro.com/rec/ Como yo salgo el último, no me veréis hasta casi la una. Pero no hay problema: el domingo 2 de Mayo, a las 21:30 horas, repiten el programa en CNN+ !y además, añaden un debate de una hora de duración! Aparecen como invitados Francisco Marto (Detective de Método 3), David Barroso (de la empresa de seguridad informática S21Sec) y este humilde aficionado a la criptografía. Creo, sinceramente, que os lo pasaréis bien. Yo, al menos, lo pasé pipa. Que lo disfrutéis todo, y hasta la próxima.

 


 

  TEMAS DE ACTUALIDAD - Cuando las claves no aparecen: el caso Childs

 

Uno de los problemas que se nos viene a la cabeza cuando hablamos de claves criptográficas es: ¿y si las pierdo? Si nosotros mismos olvidamos nuestra clave, o perdemos la copia que hicimos en papel, podemos vernos en la tesitura de que nosotros mismos no podamos acceder a nuestros propios datos.

En el mundo no digital, resolvemos este problema de diversas formas. Si, una vez cerrada la puerta de la casa, descubro que me dejé la llave en la mesita de noche, no me preocupo demasiado porque sé que mi esposa tiene una copia en su bolso. En el caso de que también ella se haya dejado sus llaves en casa, puedo ir a casa de mi suegra, donde guardamos una copia. En caso extremo, puedo llamar a un cerrajero, el cual puede que rompa la cerradura pero me abrirá la puerta.

En criptografía puede hacerse algo parecido. Podemos hacer copias de nuestras claves, y mantenerlas protegidas. En un entorno corporativo, puede que el administrador tenga una copia para emergencias (o por si me atropella un camión y hay que imprimir ese informe de forma urgente). Hay muchas soluciones técnicas, y la mayoría de ellas pasan por una persona de confianza, alguien con capacidad técnica para gestionar un sistema de claves y al que se le considera responsable y de confianza. Buena la haríamos si confiásemos nuestras claves a alguien irresponsable o malicioso, capaz de hacernos chantaje. ¿Se imaginan lo que podría pasar? En San Francisco lo saben perfectamente.

Hace un par de años, Terry Childs era un administrador de redes que trabajaba para el ayuntamiento de San Francisco. Por razones que permanecen poco claras, en Junio de 2008 Childs comenzó a jugar al Gran Hermano. Tras rastrear lo que los demás administradores decían acerca de él, pasoó a controlar el sistema. Para ello, creó una contraseña que le daba total acceso a la red de ayuntamiento, al tiempo que se lo negaba a los demás administradores.

En realidad, solamente tuvo éxito parcial. Si bien consiguió negar el acceso a los demás administradores, la red siguió funcionando con relativa normalidad. Según se ha conocido después, Childs configuró los routers con un comando que hubiera borrado sus datos de configuración en el caso de acceso por otros. Puesto que no había copia de respaldo de esos datos de configuración, los administradores legítimos no hubieran tenido otra opción que la de reconfigurar toda la red de la ciudad. Es algo así como resetearlo todo, lo que hubiera supuesto a la ciudad un coste de varios millones de dólares.

En un principio, Childs se negó a revelar las contraseñas, pero un mes después de su arresto accedió a entregarlas al alcalde en persona, ya que decía que es la única persona en quien podía confiar. Como resultado, la ciudad recuperó el control total de la red.

Los motivos de la acción de Childs siguen poco claros. Algunos empleados del ayuntamiento comentaron que su, su rendimiento era bajo y sus supervisores habían intentado librarse de él durante meses. Según esa hipótesis, Chids se construyó una especie de póliza de seguro contra despidos (más bien, un secuestro con rehenes). Otros lo describen como un empleado trabajador modelo, que sencillamente se vino abajo frente a la presión laboral. Desde 2000, más de la mitad de puestos de trabajo del servicio de informática del ayuntamiento fueron eliminados, y sus trabajadores ubicados en otros departamentos.

Sorprende leer que, a pesar de lo que hizo, Childs tiene el apoyo de muchos de sus compañeros. "Los gerentes no entienden lo que realmente hacemos, y no aprecian la complejidad de nuestro trabajo," dijo uno de ellos. ¿Un nuevo episodio en la guerra entre los informáticos y los chupatintas? Según otra hipótesis, Childs era uno de los pocos que entendían el funcionamiento de la red del ayuntamiento, y sus acciones podrían ser justificadas desde el punto de vista de la seguridad: cerrar el acceso a todos los demás, no vaya a ser que destrocen la red.

La defensa basó su estrategia en presentar el asunto como una disputa laboral que fue demasiado lejos. La negativa de Childs a entregar las claves no sería una prueba de extorsión sino al contrario: se negó a entregárselas a personas no autorizadas y sin conocimientos técnicos adecuados. De los cuatro cargos que se le imputaban, la defensa consiguió que se retiraran tres de ellos, los relativos a "proporcionar los medios para acceder a una red informática," argumentando que dichos "medios" eran módems que Childs necesitaba para llevar a cabo su trabajo como administrador.

El cuarto cargo, "interrumpir o negar servicios informáticos" es algo difícil de demostrar, ya que los usuarios de la red realmente no sufrieron una denegación de acceso a servicios. Es más, esa ley se redactó para evitar el vandalismo electrónico por parte de terceros. Si alguien fue empleado para constriur y mantener una red, no hubo daños y nadie sufrió restricciones en el servicio ¿puede aplicársele esa norma? Ciertamente, se cerró el acceso a los demás administradores; pero que dicho acceso se pueda considerar un "servicio" resulta poco claro.

La fiscalía negó todas esas alegaciones. Para Conrad del Rosario, vicefiscal del distrito, "esto no fue nada más que un intento de convertirse en un empleado indispensable. Como me despidas, la red se viene abajo" Curiosamente, la fiscalía hizo una demostración pública de incompetencia criptográfica. Durante un registro, se encontraron en el ordenador de Child más de 150 nombres de usuario y contraseñas para acceder a la red privada virtual de la ciudad. ¿Y qué hizo el fiscal? Poner las claves en un documento y rotularlo como Prueba A. !Un documento público, accesible para cualquiera! Si hubiera justicia, el fiscal ocuparía otra celda. Los cargos: revelación de secretos, incompetencia y estupidez manifiesta.

Recomiendo al lector interesado en la historia que lea los artículos de Infoworld (en http://www.infoworld.com/t/security/terry-childs-admin-gone-rogue-708?source=fssr) donde se describen más detalles sobre el caso. Los articulistas son pro-Childs, aviso.


Terry Childs ha permanecido casi dos años en prisión preventiva, de la que solamente podría salir depositando una fianza de cinco millones de dólares (cinco veces la cantidad que se les pide a los sospechosos de asesinato). Pero el caso, que dura ya dos años, llegará pronto a su fin. El juicio ha concluido, y está visto para sentencia. El veredicto se conocerá en cualquier momento. Y, a despecho de las motivaciones que tuviese, pone en el tapete el problema eterno de la confianza, del cual depende críticamente la seguridad de cualquier sistema, por mucho algoritmo criptográfico que haya por medio.

APÉNDICE: Casi al cierre de edición de este Boletín, llega la noticia. Terry Childs ha sido declarado culpable. La sentencia no se conocerá hasta el próximo mes de Julio. Puesto que, según la ciudad de San Francisco, los daños que ocasionó superaron los 200.000 dólares, podría ser condenado a hasta cinco años de prisión, de los cuales ya ha cumplido dos como prisión provisional.

 


 

 TEMAS DE ACTUALIDAD - Reventando A5/1

 

La telefonía GSM es insegura. Eso lo saben todos los que han hurgado un poco en sus interioridades. No solamente sus algoritmos de cifrado usan claves de longitud poco adecuada, sino que tienen debilidades. Peor aún, algunos gobiernos los debilitan deliberadamente. A finales del pasado Diciembre, el New York Times anunció que dicho algoritmo había sido ... bueno, roto. Esto resulta algo raro, ya que ¿no ha sido criptoanalizado antes? ¿Acaso ha introducido mejoras a los ataques conocidos hasta ahora?

Como nos gusta meternos en harina, vamos a aprovechar la oportunidad para aprender. Veremos primero cómo es el algoritmo A5 (en sus diversas variantes); después veremos por qué son débiles; al final, entenderemos en qué consiste la noticia del NYT. No teman, lo haré tan ameno como queramos.

Primera etapa: los algoritmos. Necesitaremos comprobar la identidad del usuario, intercambiar con él una clave de forma segura, y al mismo tiempo no comprometar la clave que intercambien. Para ello, el sistema GSM utiliza tres algoritmos: el de autenticación (A3), el de cifrado (A5) y el de generación de claves (A8). En realidad, A3 y A8 no son el nombre de un algoritmo en concreto, sino una etiqueta genérica. Es decir, es como poner "la caldera de gas" en un plano de un piso, en lugar de indicar marca y modelo. Y, de hecho, al igual que la caldera de gas (que nos da agua caliente para la ducha o para la calefacción), A3 y A8 son habitualmente el mismo algoritmo. Es decir, según como lo usemos, nos autentica al usuario o nos genera las claves. El algoritmo usado habitualmente como "caldera de gas" es el llamado COMP128. Pero no vamos a examinarlo. Al menos, no hoy.

El proceso de autenticación viene dado de la siguiente forma. Supongamos que mi móvil entra en la zona de cobertura. En ese momento, mi móvil envía una señal inicial a la antena más próxima, una especie de "hola, estoy aquí." La antena da el aviso a la red (más concretamente, a una parte denominada HLR), y como respuesta recibe un triple paquete de datos que consta de: la clave Ki (que solamente conocen la red y nuestro móvil); un paquete aleatorio de datos RAND; y una respuesta SRES. Dicha respuesta firmada se ha obtenido aplicando el algoritmo de autenticación A3 al que se han introducido como elementos de entrada la clave Ki y el paquete RAND. Es decir:

A3(Ki;RAND)=SRES

A continuación, la antena envía al móvil el paquete aleatorio RAND y espera respuesta. Si, y sólo si, el móvil contiene la clave Ki, podrá obtener de nuevo la respuesta SRES. Si es así, el móvil es autenticado.

Es decir, ambas partes (la antena y el móvil) han de calcular el mismo SRES a partir de los mismos datos (Ki y RAND). Si el móvil calcula un SRES distinto, es porque, o bien no ha usado el Ki que dice tener ("alerta, móvil pirata"), o bien usó un RAND distinto ("alerta, nos están dando la respuesta de la semana pasada"). Bien, esta explicación no era realmente necesaria, pero la incluyo para que captéis la imagen completa.

Una vez satisfecha la red de que nosotros somos nosotros (o más bien, que nuestro móvil es nuestro móvil), pasamos al intercambio de claves. Como en casos similares que hemos comentado aquí, lo último que haríamos sería mandar la clave de cifrado por las buenas. Ya puestos, podríamos abrir la ventana y gritar el PIN de nuestra tarjeta. Lo que se hace es aprovechar la clave Ki que conocen el móvil y la red, y usar el algoritmo A8 para enviar una clave de cifrado.

El proceso es este. Primero tomamos Ki y RAND, lo metemos en el algoritmo A8 y sacamos la clave de sesión, que llamaremos Kc. Luego cogemos el algoritmo de cifrado A5, encriptamos la clave Kc y la intercambiamos. A partir de aquí, la clave Kc se usa para cifrar la conversación.

Una vez terminado el bosquejo general, pasemos a los detalles. Vamos a ver de qué pie cojea el algoritmo A5. La verdad es que este algoritmo ha tenido una historia muy peculiar. Dice la leyenda que, cuando se redactaron los protocolos GSM, hubo una pelea entre los franceses, que querían un algoritmo relativamente fácil de romper, y los alemanes, que querían un sistema más robusto para evitar escuchas de sus vecinos del Este. Finalmente, los franceses se llevaron el gato al agua.

Los detalles del algoritmo A5 no fueron revelados, en un nuevo ejemplo de "seguridad mediante oscuridad." Pero acabó habiendo filtraciones. Según el libro "Applied Cryptography", una compañía telefónica británica envió una copia de las especificaciones GSM a la Universidad de Bradford, pero se les olvidó pedir que firmasen el típico documento en el que se comprometen a no desvelar la información. Se hicieron copias, se colgaron en Internet, y se acabó el secreto.

Una de las cosas que se pudieron confirmar es que la clave de sesión Kc, supuestamente de 64 bits, contenía realmente menos bits. De hecho, !diez de esos 64 bits son siempre iguales a cero! Esto generó en su momento una viva polémica, ya que reduce el espacio de claves a una milésima parte. Es decir, a todos los efectos, la clave Kc es de tan sólo 54 bits. Según las telecos, esos diez bits cero "proporcionan una flexibilidad adicional en respuesta a amenazas de fraude y de seguridad." Saque cada cual sus propias conclusiones.

Durante los últimos 12 años, diversos investigadores han atacado los algoritmos de protección de GSM. En 1998, atacando el algoritmo A3, se consiguió obtener la clave Ki característica de cada móvil. Es decir, se consiguieron clonar un móvil, algo que en teoría no era posible. Posteriormente, se atacó A5 en todas sus vertientes. Y es que el algoritmo A5 tiene diversos "sabores." Dependiendo de su uso, puede hacerse más o menos fuerte. La variante A5/0 es la nula, es decir, sin cifrado. La A5/2 es una versión debilitada para la exportación (recordemos que, en los años noventa, los países eran muy reticentes a permitir la exportación de material criptográfico considerado fuerte). Finalmente, la A5/1 es la versión "fuerte", usada en Estados Unidos y Europa Occidental.

Vamos a echarle un vistazo a A5/1. Su núcleo es una combinación de tres registros LSFR, con longitudes de 19, 22 y 23. No vamos aquí a repetir las propiedades de los registros lineales de desplazamiento con retroalimentación LSFR, pero el lector interesado puede refrescar conceptos en el Boletín ENIGMA 74 ("LSFR y pseudoaleatoriedad"), donde vimos el papel que juegan los LSFR como generadores de bits pseudoaleatorios. Por cierto, que allí traduje incorrectamente LSFR como "registradores lineales de retroalimentación lineal."

En A5/1, los tres LSFR se combinan para construir un algoritmo de cifrado en flujo ("stream cipher"). Esta combinación tiene sus sutilezas. Cuando tenemos un LSFR, vimos que los bits que forma iban avanzando en ciclos: en cada ciclo, creamos un bit y al mismo tiempo descartamos otro. Pero aquí, tenemos tres registros LSFR (a los que llamaremos R1, R2 y R3), y el avance o no de cada registro depende de los demás LSFR. Lo que se hace es designar un bit como "bit de reloj." Se examinan los bits de reloj de los tres registros, y se obtiene el bit mayoritario (es decir, el que ha ganado la votación entre los tres). Si el bit de reloj de un registro coincide con el mayoritario, el registro avanza; si no, se queda quieto. Para entendernos, es como tres amigos que lanzan una moneda al aire. Si salen dos caras y una cruz, el amigo que ha sacado cruz paga la ronda.

Durante la primera década de este siglo, se han desarrollado diversos ataques criptoanalíticos contra el algoritmo A5/1. Aunque diversos en naturaleza, permiten reventar el sistema (en el sentido de que podemos obtener la clave de sesión Kc sin necesidad de probar todas las claves posibles). Suelen ser ataques pasivos, en los que solamente se captan bits. El problema fundamental es que, aunque roto, A5/1 es bastante sólido, y los ataques pasivos (tan rápidos, que en ocasiones pueden considerarse "en tiempo real" requieren de una etapa previa penosa. ¿Qué queremos decir con "penosa"? Los datos exactos dependen del tipo de ataque, pero digamos que miles de ordenadores y una capacidad de almacenamiento que se mide en terabytes.

Sin embargo, el ataque definitivo es el de fuerza bruta. No importa si A5/1 es vulnerable criptoanalíticamente, porque si pudiésemos probar todas las claves, en principio podría ser derrotado. Eso es algo general a cualquier algoritmo. En el caso de A5/1, con claves de 64 bits, habría que probar 2^64 claves. La idea es la siguiente. El estado interno del algoritmo es un dato que, en principio, no conocemos. Pero sí sabemos que, una vez dicho estado ha sido fijado en el algoritmo, nos dará como resultado una cadena de bits de salida. Así que no tenemos más que construir una gigantesca tabla que nos relacione el estado interno con la salida que obtenemos.

De ese modo, supongamos que hacemos un simulador del algoritmo A5/1. Le introduzco el estado interno A52F8C02 (que me representa la forma en que los registros LSFT están dispuestos), y el resultado que obtengo es 52E01001. Eso implica que, cuando ponga la oreja en una conversación telefónica y capte "52E01001," ya sé que el estado interno es el correspondiente a A52F8C02. A partir de ahí, "ajusto" mi móvil (o mi emulador de PC) de forma que el estado interno sea A52F8C02, y a partir de ahí reproduzco los mismos procesos que se llevan a cabo en el móvil del usuario legítimo.

Eso significa que tenemos que construir una tabla correspondiente a los 2^64 estados del algoritmo, y sus correspondientes flujos de cifrados. Debido a la forma en que los datos vienen empaquetados para la telefonía móvil, el tamaño de la tabla se reduce a unos 2^57 bytes. Y aquí está el problema. En los años noventa, 2^57 bytes eran algo casi inimaginable, lo que en la práctica excluía la posibilidad de crear una tabla que englobase todas las posibilidades. Del número de cálculos que habría que realizar, mejor ni hablar.

Pero en aquella época, un disco tenía una capacidad de apenas un megabyte y medio, y hoy tengo en el cajón del despacho una unidad USB de 16 gigabytes. Eso hace que reventar A5/1 mediante fuerza bruta sea posible en principio, pero aún muy difícil para el común de los mortales. Para que nos entendamos, 2^57 bytes es igual a 128 millones de gigabytes, o más de cien mil veces la capacidad de un disco duro. Y eso sólo lo obtendremos si emulamos el algoritmo en un PC, le damos al botón de inicio y esperamos como 100.000 año, día arriba, día abajo.

Y aquí es donde entra el artículo del New York Times. La noticia dice que el experto alemán Karsten Nohl ha descifrado el algoritmo GSM. Bueno, no exactamente. Lo que hizo fue aprovechar diversas técnicas para reducir los requisitos de tiempo y almacenamiento de esa gigantesca tabla hasta cifras más o menos manejables 2-3 Terabytes de disco duro y un tiempo de computación de pocos meses.

El primer truco que se nos ocurriría para no tener que esperar esos cien mil años sería, lógicamente, utilizar más de un ordenador. Pero eso nos exigiría usar gran cantidad de máquinas. Lo que hizo Nohl es utilizar dos tipos de chips: los CUDA y los FPGA. Los primeros permiten utilizar los chips que gobiernan las tarjetas gráficas (y que ya están llegando a unos niveles de rapidez que rozan lo increíble); y los segundos son una especie de procesadores cuyo hardware se puede programar a voluntad. Incluso echó mano de algunas Playstation 3. Todo ello le permitió calcular todos los datos que necesitaba en apenas tres meses. Todo un logro por sí mismo.

En segundo lugar, hay que comprimir la tabla. Para ello, se convierte en lo que se llama una "tabla arco iris" ("rainbow table"). El problema es que pasar de la "gran tabla" a la "tabla arco iris" involucra lo que se llama un "trade-off", esto es, ganamos algo pero también perdemos algo. En este caso, los factores enfrentados son el tamaño y la complejidad. Una tabla arco iris pequeña será fácil de almacenar, pero cuando la usemos nos llevará más tiempo y más cálculos que una tabla mayor.

Se trata de encontrar el equilibrio óptimo, y cada cual ve las cosas de un color. Para Nohl, lo "optimo" se describe como una tabla de aproximadamente 2 terabytes de capacidad, que permita un descifrado casi en tiempo real de una conversación. Así, en diciembre de 200, Nohl expuso su propuesta de tablas arco iris en el 26º Chaos Communication Congress, organizado por el famoso CCC (Chaos Computer Club) en Berlín. En él, Nohl indicó los pasos a seguir y solicitó ayuda a voluntarios.

Por supuesto, la industria no lo tomó nada bien. En un comunicado de prensa, dan una pincelada de verdad con otra de desinformación. Refiriéndose a otro intento similar de 2007, afirman que la tabla tiene un tamaño de 2 terabytes, "que es equivalente a la cantidad de datos contenidos en una pila de libros de 20 kilómetros de altura." Quizá quieran transmitir el mensaje de que es una enormidad de datos, pero la verdad, los que estamos acostumbrados a manejar discos duros de centeneras de gigabytes (que somos prácticamente todos), no nos impresiona. Dos terabytes caben en mis tres discos duros externos, y eso que ya son algo viejos.

En segundo lugar, cargan las tintas contra la parte práctica. Dicen que "antes de intentar un ataque práctico, la llamada GSM tiene que ser identificada y guardada. Hasta ahora, este aspecto de la metodología no ha sido explicada en ningún detalle [por Nolh y su grupo], y creemos fuertemente de que los grupos que intenten desarrollar una capacidad de interceptación han subestimado su complejidad práctica." Esto es en parte cierto, si bien me huelo que no resultará tan complicado como pretenden hacernos creer. El problema es que lo que Nolh intenta NO es desarrollar un interceptador GSM práctico, sino tan sólo plasmar un ataque de fuerza bruta como prueba de concepto. Él lo deja muy claro en sus trabajos, lo que me hace suponer que la gente de la GSM Association han entendido las cosas como les ha dado la gana.

Y, en realidad, puede ser más fácil de lo que creemos. Hacen tan sólo unos pocos días, en la conferencia Source Boston 2010, los investigadores Nick DePetrillo y Don Bailey, mostraron cómo aprovechar la estructura de la red de telefonía móvil GSM para rastrear un móvil, incluyendo la determinación de su ubicación geográfica, incluso si no conocemos el número de dicho móvil. En palabras de uno de ellos, "si quieres que averigue el número de Brad Pitt, puedo volcar todos los datos de identificación de llamadas de móviles en California y buscar el número." La charla de DePetrillo y Don Bailey tiene un nombre que lo dice todo: "Hemos encontrado a Carmen San Diego" (pueden ver su presentación en http://www.sourceconference.com/bos10pubs/carmen.pdf)

Hay una frase en el comunicado de prensa de la GSMA que me ha gustado particularmente: "el complejo conocimiento necesario para desarrollar tal software [capaz de captar y procesar la señal] está sujeto a derechos de propiedad intelectual, haciendo difícil que se convierta en un producto comercial." El eterno truco: si no convences con tecnología, aplasta con los abogados. ¿Realmente se cree alguien que quien quiera violar la privacidad de los usuarios de móviles GSM se va a parar en minucias como la propiedad intelectual? Eso suponiendo que dicha propiedad intelectual proteja los algoritmos de GSM hasta ese punto. Imagino que, sencillamente, estarán siguiendo el libro de estilo de las empresas víctimas de ataques criptoanalíticos, y que se pueden resumir en:

Punto 1: lo negamos todo.
Punto 2: sí, es posible que sea cierto, pero sólo desde el punto de vista teórico.
Punto 3: sí, tal vez tenga cierta aplicación, pero sólo para personas con altos conocimientos en el ramo. Punto 4: bueno, vale, pero hacen falta grandes ordenadores y equipos sofisticados.
Punto 5: tal vez sea así, pero no les va a servir de mucho.
Punto 6: está bien, es factible, práctico y hasta fácil, pero no lo hagan porque es ilegal, inmoral y engorda.
Punto 7: !problema resuelto! Hemos creado una nueva versión mejorada, a prueba de ataques de cualquier tipo.

Y vuelta a empezar.

Cualquiera que sea la reacción de la industria del ramo, lo que está claro es que, según un experto en seguridad informática, lo que ha hecho Nolh es poner en manos de cualquiera una capacidad (siquiera teórica) de interceptación de llamadas que, hasta ahora, era patrimonio exclusivo de las agencia de inteligencia y las organizaciones del crimen organizado.

Si usted quiere meterse en el fregado, pásese por el "A5/1 Security Project" (http://reflextor.com/trac/a51). Parece que todavía están en la fase de preparación. Cuando hayan terminado los cálculos, tienen la intención de colgar las tablas arco iris en Internet, via bittorrent. Y aún se atreven a afirmar que A5/1 es tan sólo el primer paso. Según Nohl, este esquema de pre-computación masiva es factible para cualquier algoritmo de cifrado de hasta 64 bits.

 


 

 TEMAS DE ACTUALIDAD - A corazón abierto III: tus claves donde yo pueda verlas

 

En el boletín ENIGMA 72 examinamos el problema de los marcapasos, vistos como instrumentos que intercambian datos con el exterior. El control de dichos datos implica la necesidad de criptografía, pero en este caso tenemos el problema adicional de que no siempre el usuario está capacitado para poder ejercer dicho control. O, dicho de otra forma, una persona que esté siendo atendida por un equipo médico de urgencias tendrá otras cosas en la cabeza además de la clave de su marcapasos.

Se trata de un escenario de esos que los americanos llamarían "no-win situation." Si no usamos cripto, los datos personales y médicos del paciente estarán a disposición de cualquiera, y su propia vida podría peligrar si alguien accede inalámbricamente a las funciones de control del dispositivo; si usamos cripto, puede resultar un estorbo para los médicos de urgencias, y el latiguillo de "traed el carro de paradas" que vemos en las películas sería sustituido por una frenética llamada tipo "las claves, las claves, hay que encontrar las claves"

Nos encontramos aquí, por tanto, con un problema de gestion de claves, que puede llegar a ser literalmente cuestión de vida o muerte. De ahí que se hallan desarrollado diversos esquemas para resolverlo. Alguno ya lo dimos en el Boletín ENIGMA 72. Hoy quiero mostraros una innovadora solución que acaba de proponer Stuart Schechter, de los laboratorios de investigación de Microsoft: tatuajes ultravioleta.

La solución es sencilla y elegante. El paciente escoge una clave a su gusto, y se la hace grabar en la piel mediante una técnica de micropigmentación, un tatuaje, vamos. Para que sea útil debería grabarse en un lugar de fácil acceso, y que a la vez esté razonablemente protegido de abrasiones o daños de otra índole. Schechter propone la planta del pie izquierdo. Cualquier dispositivo que tenga que acceder a la clave estará dotado de una luz ultravioleta y de un teclado para introducirlo manualmente, si bien es en principio posible que el aparato pueda reconocer los caracteres y usarlos directamente. De hecho, no hace falta que sean siquiera caracteres alfanuméricos. ¿Imaginan una clave formada por jeroglíficos egipcios? Tal vez estemos viendo el inicio de una nueva tendencia: los cripto-tatuajes.

El hecho de que el tatuaje sea solamente legible bajo la luz ultravioleta permite resolver un problema de seguridad (básicamente, llevar una clave sin que nadie pueda verla), pero asimismo intenta resolver dilemas morales. En general, los tatuajes son escogidos libremente por sus usuarios, y si Angelina Jolie decide tatuarse la guía telefónica en el hombro izquierdo, es cosa suya (bueno, y de sus mil millones de fans, pero esos no cuentan aquí). Por mi parte, reconozco que no me gustan los tatuajes, y no considero a una mujer más atractiva porque lleve uno (aunque, en el caso de Angelina, estoy dispuesto a sacrificarme).

Por otro lado, los ciudadanos de países libres siempre hemos sido muy reticentes a la hora de admitir el uso de cualquier tipo de tatuaje o pigmentación como marca de identificación. Incluso sin evocar los recuerdos de Auschwitz, el hecho es que no nos gusta ir con nuestra identificación a la vista de todos.. El propio autor lo escribe bien claro:

"Durante el holocausto, los tatuajes de identificación recordaban a los prisioneros que ya no controlaban su propio cuerpo. Dejar al paciente la elección de usar o no la micropigmentación, el tipo de codificación a usar y algún control sobre el proceso que genera la codificación debería resultarle de ayuda"

Y es que en los países libres, a los ciudadanos nos gusta identificarnos sólo en las condiciones en que escojamos nosotros, y no en otros casos. Tener a gente leyendo automáticamente nuestros tatuajes identificativos en el Metro es algo que puede que no a todos nos guste.

El sistema de tatuaje también tiene sus inconvenientes. Algunos pacientes pueden sufrir irritaciones en la piel, o quizá algún riesgo a largo plazo para la salud. También son susceptibles a daños físicos, como quemaduras o amputaciones. Incluso manchas de grasa o sangre pueden entorpecer la lectura de la clave. Quizá sería conveniente hacer copias del tatuaje en varias partes del cuerpo. Y eso no resolvería un problema peliagudo: el del cambio de claves. Si por cualquier motivo hay que cambiar la clave del marcapasos (por ejemplo, porque haya sido sustituido por otro), ¿cómo lo hacemos? ¿Tachamos el tatuaje antiguo y marcamos al paciente con uno nuevo?

La actitud de los pacientes respecto a este método será determinante para saber si resultará útil en la práctica. De hecho, un equipo de informáticos y médicos (que incluyen uno de los firmantes del artículo sobre marcapasos y seguridad que examinamos en el Boletín ENIGMA 72) realizaron un estudio sobre la reacción de la gente a diversos tipos de sistemas de seguridad para proteger las claves de los marcapasos. Estos sistemas (algunos de los cuales no se han desarrollado del todo) consistían en brazaletes y chapas de alerta médica, así como tatuajes tipo código de barra bidimensional (en sus versiones visible y ultravioleta).

No faltaba en el estudio la referencia al pasado: "Los autores tenían reticencias acerca de incluir identificadores basados en tatuajes, especialmente considerando una posible asociación con el tatuado de prisioneros en campos de concentración durante la Segunda Guerra Mundial ... teníamos la hipótesis de que ese sistema, si bien satisfactorio desde el punto de vista técnico, no sería satisfactorio desde el punto de vista del paciente." Más claro, agua, y tanto más necesario conocer el punto de vista del paciente.

Se escogió un grupo de trece personas voluntarias con "amplia experiencia" en el tema. Es decir, todos llevaban marcapasos (algunos por segunda vez), y su edad media rondaba los 68 años. A todos ellos se les explicaban los pormenores de los tres sistemas (brazaletes, tatuajes visibles y tatuajes ultravioleta), y se les preguntó por cuál de ellos les gustaba, cuál no les gustaba, y cuál escogerían.

Los resultados son poco significativos desde el punto de vista estadístico (solamente 11 respuestas válidas), pero algo es mejor de nada. La opinión general es que el brazalete es la solución preferida. El tatuaje visible sería un fracaso: ni uno solo de los entrevistados lo hubiera escogido. Sin embargo, un tatuaje ultravioleta sería aceptado por un mayor número de personas. Algunos entrevistados, preocupados por la seguridad, expresaban sus temores acerca de que el personal médico no pudiese encontrar el tatuaje, o bien no tuviesen luz lectora ultravioleta a mano. Para ser ecuánimes, también hubo dudas sobre el funcionamiento de un brazalete con el código impreso.

En el apartado de la privacidad, hubo de todo. A un participante le disgustaban los tatuajes porque los asociaba con borrachos. Otro fue brutalmente sincero: "para mí, un tatuaje en el brazo me recuerda a un campo de concentración." Curiosamente, una mujer no tenía más problemas que los de imagen. Llevar un tatuaje, decía, mostraba una imagen distinta a la que quería proyectar a los demás, una especie de "está bien, pero es que no mola."

Pero los tatuajes gozan de una ventaja adicional, según los participamentes del estudio: son discretos. A algunos no le gustó eso de tener que ir por ahí con un brazalete en la muñeca, como diciendo "tengo un marcapasos" a todo el mundo. Para uno de ellos, el mero hecho de llevar algo que les recordaba constantemente su condición de paciente con marcapasos resultaba molesto. "Me sentía como un inválido", dijo uno de los entrevistados. Otros problemas incluían las molestias derivadas de tener que llevarlo a todas horas, recordar quitárselo en la ducha, temores a que se enganche con otros objetos, etc.

En resumen, si bien los brazaletes parecen ganar esta partida, hay ventajas inherentes al uso de tatuajes, a condición de que sean discretos, que en este caso signifa invisibles a la luz normal. Si los médicos tienen la sensibilidad suficiente para poder hacerlos sin que recuerden a los tatuajes de los campos de exterminio nazi (por ejemplo, nada de ponerlos en el brazo), pueden ser una alternativa válida no sólo desde el punto de vista de la seguridad, sino de la aceptación por parte de los pacientes.

Y, por qué no reconocerlo, queda de lo más molón. En cuanto veamos a Shakira anunciar que se ha hecho un tatuaje de alerta médica, comenzarán a ponerse de moda. El único problema que veo es éste: va a haber bofetadas en el hospital para ver quién se encarga de tatuarle el código. Sobre todo, si se escoge alguna parte del cuerpo especialmente oculta y capaz de albergar claves de gran tamaño. De hecho, creo que debería enviarle una copia de este boletín, y ofrecerle mis servicios técnicos ahora mismo.

 



El boletín ENIGMA es una publicación gratuita del Taller de Criptografía, y se rige por las normas de la licencia de Creative Commons Reconocimiento-NoComercial-CompartirIgual. Se permite su libre copia, distribución y comunicación para fines no lucrativos, citando nombre y referencia.

Para más información, véase la licencia Creative Commons en sus formas reducida y completa:
http://www.cripto.es/licencia/deed.es.htm
http://creativecommons.org/licenses/by-nc-sa/2.5/es/legalcode.es

PARA DARSE DE ALTA: envíe un mensaje a la dirección alta arroba cripto.es añadiendo las palabras alta_enigma en el asunto (subject).

PARA DARSE DE BAJA, envíe un mensaje a la dirección baja arroba cripto.es añadiendo las palabras baja_enigma en el asunto (subject)

Para comentarios a este boletín (dudas, preguntas, consultas, críticas, noticias, colaboraciones, etc.), estoy a su disposición en la dirección noticias arroba cripto.es

Página del Boletín Enigma (incluyendo números atrasados): http://www.cripto.es/enigma.htm

(c) Arturo Quirantes 2007

 


Vuelta a la Página principal del Boletín ENIGMA