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