Boletín ENIGMA - nº 72

1 de Diciembre de 2009

 


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


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


EDITORIAL

TEMAS DE ACTUALIDAD - Deconstruyendo SSL

TEMAS DE ACTUALIDAD - A corazón abierto I

TEMAS DE ACTUALIDAD - A corazón abierto II

 


 

 EDITORIAL

 

Según hemos conocido este mes, el FBI ha adquirido un montón de estas máquinas de videojuegos PlayStation 3. Y no para jugar a CSI o a Modern Warfare 2, dicen ellos con cara muy seria. Por lo visto, la PS3 tiene diversas propiedades que la hacen especialmente atractiva para probar contraseñas y crackear claves: procesadores rápidos, capacidad de calcular en paralelo o posibilidad de correr Linux. Si es cierto lo que he leído, una PS3 es capaz de hacer lo mismo que un Dell de ocho mil dólares.

Ya existe un cluster de 336 PS3s, propiedad de la Fuerza Aérea de EEUU, que será próximamente ampliada con otras 2.200 máquinas recién adquiridas, según dice para análisis de imágenes digitales. Dejaré a vuestra malicia imaginar hasta qué punto la noticia es cierta, y hasta qué punto los pilotos y Hombres G desean, sencillamente, jugar a marcianitos. No puedo por menos que recordar cómo, en 2000, se sugería prohibír a Sadam Hussein la importación de PlayStation 2, con el argumento de que podría usarlas para calcular datos balísticos de misiles o diseñar armas nucleares.

El hecho es que estas máquinas, diseñadas para darnos entretenimiento, son por derecho propio superordenadores en cuanto a sus prestaciones. Aún no tengo noticia de que nadie, fuera del FBI, utilice las modernas consolas para descifrar contraseñas.

¿Quiere usted ser el primero? Vamos, anímese y envíenos sus planes para implementar un simulador de Enigma o un sistema de cifrado creado por usted. Fíjese que le estoy dando una excusa magnífica para comprarse una PS3 en plena época de crisis: !no es para jugar, es para crackear contraseñas!. Yo ya tengo la Wii, así que no va a colar, pero aproveche usted si puede. Y si es usted de corte más clásico, olvídese de corbatas o iPhones, nada mejor que una vista por www.cryptex.org.

Bromas aparte, parece que últimamente veo cripto por todas partes. Y no es para menos, después de haberme metido a investigar el cifrado de calculadoras y máquinas fotográficas. Este mes seguiremos en esa línea, examinando los problemas y soluciones de un tipo de dispositivos que lo necesitan como el comer. Léalo, y disfrútelo, en los dos artículos "A corazón abierto". Después, aprovecharemos la noticia de una recientemente descubierta vulnerabilidad en SSL para examinar dicho protocolo, y ver hasta qué punto es grave el fallo.

Y con esto nos metemos en Navidades. Ignoro si podré preparar el ejemplar de Diciembre, que servidor tiene mucho que hacer esos días, como descansar, preparar los mantecados y descifrar el enigma de qué les van a traer los Reyes Magos a mis enanos (este año prefieren a Papá Noel, porque dicen que así pueden jugar todas las navidades; no saben nada, esos dos). Quizá sea mejor que todos, ustedes y yo, nos dediquemos a descansar cuerpo y mente, cargar las pilas de optimismo y disfrutar de estos días. Y, sobre todo, hacernos a la idea de que los nubarrones seguirán en el cielo, y muy negros, pero por mucho que sople el viento un día dejará de golpearnos y dará paso al sol radiante. Que no hay mal que cien años dure. Felices, muy felices, fiestas a todos, y arriba los corazones.

 


 

  TEMAS DE ACTUALIDAD - Deconstruyendo SSL

 

Algunos de los primeros Informes que escribí para mi Taller de Criptografía se referían al protocolo SSL, que gobernaba (y gobierna) las transacciones electrónicas seguras. Parece que fue ayer, pero corría el año 1997 o 1998, y ya ha llovido en Internet desde entonces. Parece que está de moda mirar atrás en el tiempo, quizá por la creencia de que cualquier tiempo pasado fue mejor, o sencillamente porque esté de moda, así que ¿por qué no desempolvar al viejo Secure Socket Layer y echarle un vistazo? Hay otro motivo, algo más oscuro, que revelaré más adelante.

Mi primera explicación sobre SSL, que todavía puede consultarse en http://cripto.es/informes/info004.htm, es algo esquemática, pero en lo fundamental vale para fines didácticos. Los detalles técnicos sobre capas, encapsulamiento de datos y demás finuras, es algo que podemos saltarnos para ir a lo fundamental. La idea básica es efectuar un intercambio de claves simétricas para llevar a cabo un cifrado simétrico, usando para dicho intercambio criptografía de clave pública.

Recordemos las ventajas e inconvenientes de ambos sistemas. El cifrado simétrico es rápido y eficaz, pero siempre tenemos el problema del intercambio de claves. La criptografía de clave pública alivia dicho problema, pero matemáticamente es un proceso lento y laborioso, y siempre queda la incógnita de si la clave recibida es realmente de quien dice ser. SSL es un sistema híbrido, que combina lo mejor de ambos mundos.

Veamos cómo. El ejemplo típico es el del usuario U que quiere conectar con el banco B de forma segura (a ambos interlocutores se les denomina genéricamente "cliente" y "servidor"). En su primera fase, el cliente U envía una petición al servidor B pidiendo una sesión cifrada. En el lenguaje del ramo, eso recibe el nombre de "Client Hello", y realmente es poco más que decir "hola, soy yo, ¿podemos hablar? Acepto los siguientes algoritmos de cifrado: ..." El servidor B, por su parte, toma nota de qué tipo de cifrado puede usar el cliente U, escoge el tipo de cifrado que considere más adecuado, y envía al cliente un "ServerHello".

En este punto, solamente han acordado qué tipo de sistema de cifrado van a usar, y el siguiente paso consistirá en "negociar" un intercambio de claves. El servidor B envía al cliente U una clave pública. Por supuesto, cualquiera puede haber creado dicha clave pública, así que ¿como puede el cliente verificar que dicha clave pertenece al banco B?

Es aquí donde entran las autoridades de certificación (AC), que son una especie de notarios o terceros de confianza. La clave digital del servidor B irá firmado por alguna AC, la cual dará fe de que dicha clave pertenece a B. AC ha firmado la clave de B con una clave privada, así que si nosotros tuviésemos la clave pública correspondiente, podríamos comprobar que dicha certificación es válida. ¿Dónde se encuentran dichas claves públicas? Pues en nuestros navegadores, ya que el protocolo SSL se utiliza en las conexiones http. El único problema es que las claves públicas, por algún motivo, reciben en este entorno el pomposo nombre de "certificados digitales", pero siguen siendo claves públicas.

Por ejemplo, mi navegador Firefox me permite ver las claves públicas de muchas AC, en la Opciones / Avanzado / Ver Certificados / Autoridades. Aparecen un montón, desde Türktrust hasta Xramp Security. Si pulso "ver" aparecen los principales datos de la clave. Dicha clave aparecen en un certificado X.509, que incluye diversos datos importantes como entidad emisora, número de serie, período de validez, etc. En Internet Explorer los datos se pueden obtener de forma similar en Herramientas / Opciones de Internet / Contenido / Certificados / Entidades Emisoras Raíz de Confianza. Se supone que el servidor B se ha gastado los cuartos en buscar una AC que certifique sus claves.

De ese modo, el cliente ha recibido un certificado digital formado por la clave pública de B, firmada por una AC. El cliente B (o mejor dicho, su navegador), toma la clave pública de la AC y comprueba que efectivamente, la clave de B está correctamente firmada. A partir de aquí U puede fiarse de que la clave de B realmente proviene de B, y da el siguiente paso. Dicho paso consiste en crear una clave simétrica de sesión, cifrarla con la clave pública del servidor y enviársela. El servidor B, por su parte, toma su propia clave privada para descifrar el mensaje y obtener la clave de sesión, que llamaremos K. A partir de aquí tanto U como B se comunican por medio de un sistema simétrico con clave K. Cuando se acabe la comunicación, se tira la clave K y se acabó lo que se daba.

El protocolo SSL 2.0, ya en desuso, permitía usar algoritmos de cifrado con claves pequeñas, lo que le otorgaba poca seguridad (para los lectores interesados, les recomiendo los primeros Informes de este que escribe, disponibles en http://cripto.es/informes.htm). El protocolo 3.0, más usado en la actualidad, también permite cifrado débil por motivos de compatibilidad, pero lo habitual es usarlo con cifrado de tipo fuerte (AES o TripleDES), junto con algoritmos de clave pública RSA y de firma SHA-1. En cuanto al protocolo TLS 1.0, tiene leves diferencias, pero en lo que nos toca son poco relevantes.

Así nos aseguramos de que nuestro banco digital es realmente nuestro banco digital. Con todo, el sistema tiene sus fallos. Uno de ellos es que, si yo me conecto a mi banco, el proceso anterior me permite asegurarme de que ese es realmente mi banco, pero ¿cómo sabe mi banco quién soy yo? Respuesta: no lo sabe. Nosotros no vamos creando certificados digitales y repartiendo claves públicas (al menos, el usuario medio; de los lectores de este Boletín, me espero otra cosa), así que nuestro banco nos proporciona diversos métodos de autenticación: claves numéricas, tarjetas de coordenadas, etc.

Normalmente, los malos de la película tienden a atacar el eslabón más débil: el usuario. El proceso es el siguiente. Digamos que, tras leer este estupendo Boletín (lo siento, no tengo abuela ;-), recibe usted un mensaje spam que dice algo así como "Hola, somos su banco. Hemos detectado problemas de seguridad. Por favor, pulse aquí e introduzca de nuevo sus datos y contraseña". "Aquí" es una direccion web que, en nuestro programa de correo, dice www.banco.com. Sin embargo, es un juego de niños asociar dicha dirección con otra falsa, de forma que cuando usted pulsa, se conecta con una página falsa, digamos www.ban.co.com. Allí le han preparado una web de entrada que imita la de su banco. Usted se lo cree, porque tiene buena pinta, y puede que incluso vea el símbolo del candado. Todo imitación. Tal vez si hubiese pinchado en él, y leído la información del certificado digital, se habría dado cuenta, pero ¿cuántas personas hacen eso? En estos casos, la mejor protección es la del sentido común. Nunca de información privada si se la piden. Y si insisten, cambie de banco.

El protocolo SSL funciona desde hace una década larga, y de su sucesor TLS esperamos el mismo éxito y fiabilidad. Imagínense, por tanto, el revuelo que se montó cuando se hiza pública una vulnerabilidad MITM ("man-in-the-middle", o ataque "hombre entre medias") en SSL y TLS. Este tipo de ataques suceden cuando una tercera persona consigue introducirse en medio de la comunicación. El ejemplo típico es el siguiente. Alicia y Benito quieren intercambiar sus claves públicas, así que Alicia le envía la suya. Pero Carlos la intercepta, y le envía a Benito una clave falsa. Cuando Benito envía su propia clave, Carlos vuelve a interceptarla y suplantarla. De ese modo, Alicia y Benito creen comunicarse de forma segura, pero no saben que hay alguien que descifra sus mensajes, los lee y los retransmite.

¿Cómo es posible que se pueda hacer eso en SSL? A fin de cuentas, todo ese rollo de los certificados digitales y las AC se diseñó para evitar ese tipo de ataques, ¿no? La noticia se publicó originariamente en http://www.links.org/?p=780 con el título "Otro Protocolo Muerde el Polvo" ("Another Protocol Bites the Dust", en evidente alusión al tema musical de Queen),saltó luego a slashdot.com, y ya se montó la gorda.

La raíz del problema yace en la renegociación. Como vimos anteriormente, la finalidad de SSL o de TLS es permitir el intercambio de una clave de sesión, a partir de la cual ambas partes pueden intercambiar información de forma segura. En la mayoría de los casos, con eso basta y sobra. Pero hay ocasiones en que es necesario un "refresco". Puede que, en un momento dado de la transacción, una de las dos partes decida que es mejor elevar el nivel de seguridad usando un algoritmo de cifra simétrica más fuerte; o que se vea conveniente elevar el nivel de autenticación; o por el motivo que le de la gana a cualquiera de los dos . El caso es que la sesión puede ser "renegociada", es decir, se repite el proceso para intercambiar otra clave simétrica.

La pega consiste en que SSL y https van por separado, en diferentes capas, que dicen los expertos. Si fuesen invitados a una boda real, los sentarían en filas separadas. Si nos encontramos en un punto en el que se requiere una renegociación (por ejemplo, si el servidor exige al cliente que se autentifique), el servidor debe ponerse a ello y exigir dicha renegociación. A continuación, el servidor debería decirle al cliente que utilice el nuevo canal de comunicación que acaba de ser creado. Pero resulta que el protocolo http carece de un código específico para decirle al cliente que lo haga, así que el cliente utiliza la autenticación anterior. Por decirlo de modo muy basto, el servidor cambia de canal pero se le olvida decírselo al cliente.

En ningún momento ha habido fallo en el cifrado, pero el resultado es que hay una discontinuidad en el proceso de autenticación, y eso es la clave del problema, porque un atacante puede aprovecharlo para hacer de las suyas. En particular, un atacante MITM puede solicitar al servidor la renegociación y, mientras se lleva a cabo, enviar al servidor un paquete malicioso con sus instrucciones.

Digamos que el usuario legítimo U intenta conectarse a su banco www.banco.es. El MITM, que lo ve, intercepta esa petición y la deja "en espera" mientras él mismo se conecta al banco B mediante SSL y hace una petición de transferencia a enviar a su propia cuenta. En ese momento, pide una renegociación a nivel SSL (que está a otro nivel distinto a http). Cuando comienza la renegociación, el atacante da vía libre a la conexión del usuario legítimo (la que tenía "en espera"). El servidor del banco, al ver que ambas parecen venir del mismo sitio, las concatena y les da curso a las dos.

Es decir, imagínense el siguiente ejemplo telefónico con el usuario legítimo U, el atacante MITM A y el banco B:

Usuario U (llamando a B): - Hola, ¿es el banco? Soy el usuario U

Atacante A (llamando a B): - Hola, ¿es el banco? Soy el usuario U. Quiero sacar dinero de mi cuenta y enviársela a A

Banco B (hablando con A): - Sí señor, enseguida. ¿Me dice su número secreto?

Atacante A (llamando simultáneamente a U): - Sí, señor, aquí el banco B. ¿Me dice su número secreto, por favor?

(El atacante A conecta entre sí las llamadas a U y a B)

Usuario U (hablando con B): - Por supuesto, señor. Mi número secreto es 12345

Banco B (hablando con U): - Correcto, transacción autenticada. ¿Algo más?

Usuario U (hablando con B): Pues sí, vamos a ver ...

Y mientras tanto, A ha tomado las de Villadiego y su botín le está esperando en su cuenta de Isla Tortuga.

El ejemplo del banco está basado en la interpretación de Yago Jesús (http://www.securitybydefault.com/search?q=ssl). Espero haberlo entendido bien, pero si hay algún fallo sobre mi cabeza caiga.

Cuando se hizo público, este ataque MITM (por cierto, desarrollado por Marsh Ray y Steve Dispensa, de PhoneFactor Inc.) se consideró como algo posible en teoría pero con poca repercusión práctica. Pero ya ha sido probado en la práctica. Un estudiante turco llamado Anil Kurmus lo ha convertido en un ataque real, en el que consiguió robar credenciales de login en Twitter. Aunque el ataque descrito anteriormente no conseguía las claves de cifrado, ni por supuesto leer texto cifrado, Kurmus se las ingenió. Puesto que cualquier petición hecha en Twitter incluye el login de usuario y la contraseña del peticinario, hizo que la interfaz del protocolo de aplicaciones de Twitter hiciese una copia en un mensaje que el atacante pudo luego leer.

Es algo así como si Atacante, en lugar de ordenar una transferencia, dijese "hola, soy el usuario U, quiero que me envíen una copia de mi contraseña a la siguiente dirección: Atacante A, Avenida Doctor Maligno, Isla Tortuga; Y aquí va mi número secreto .." (y le pasa la llamada a Usuario).

Twitter, por supuesto, cerró el fallo en pocos días. Pero se pueden montar ataques similares contra redes que utilicen cookies para autenticación, ya que es una buena forma de robarlas o falsearlas. Una solución temporal puede ser prohibir la renegociación, y en estos momentos se están preparando soluciones al problema, como puede verse en la web http://www.phonefactor.com/sslgap/ssl-tls-authentication-patches. Mientras tanto, no pierdan el sueño. En la Escala Quirantes de Gravedad Criptográfica, yo calificaría esto como un arañazo: pica y puede ir a peor, pero tiene cura fácil.

 


 

 TEMAS DE ACTUALIDAD - A corazón abierto I

 

En los últimos ejemplares del Boletín ENIGMA, hemos visto ejemplos que raramente asociamos con la criptografía, como calculadoras o cámaras fotográficas. En todos esos casos, hemos analizado los sistemas de cifra en la medida en que hemos podido, concluyendo sobre su viabilidad de uso. A veces los algoritmos no son buenos, o no están implementados adecuadamente, y en ese caso los lectores de este Boletín se ponen las botas. Recientemente he tenido noticias de una posible aplicación muy especial de la criptografía. Especial por el tipo de dispositivo a aplicar, porque la solución no está clara, y sobre todo porque el problema a resolver puede llegar a ser, literalmente, asunto de vida o muerte.

Señoras, señores, bienvenidos al problema de la seguridad electrónica en ... los marcapasos.

Sí, marcapasos, han ledo bien. Como todos sabemos, los dispositivos que genéricamente denominamos así son necesarios para que los corazones de muchas personas sigan latiendo con regularidad. El problema con los marcapasos es que, como instrumentos que son, precisan de mantenimiento. Y, como es evidente, no es buena idea abrir el pecho del paciente cada vez que haya que ponerle una pila nueva. Felizmente, el fenómeno físico conocido como inducción magnética resuelve ese problema; y si no, las baterías actuales pueden mantener al aparato funcionando durante años. La construcción de marcapasos evita, o minimiza, la mayoría de fallos por funcionamiento mecánico o eléctrico.

En ocasiones, aparecen problemas de soporte lógico. Los marcapasos tienen su propio software ("firmware"), y algunos pueden ser configurados, lo que los hace susceptibles a errores de programación. Desde 1990, la agencia del medicamento norteamericana (FDA) ha encontrado que el 40% de los fallos de los desfibriladores implantables se deben a fallos en el firmware, lo que constituye en términos absolutos casi un cuarto de millón de casos. Y eso en aparatos que apenas pueden programarse.

Quizá fuese mejor no programarlos en absoluto. Sin embargo, es preciso ejercer algún tipo de control externo para recargarle de energía, o bien estimularlo cuando sea necesario. Análogamente, necesitaremos control sobre los demás dispositivos implantables, como sistemas de liberación de fármacos o neuroestimuladores. Aun en el caso de no requerir control externo, estos dispositivos proporcionan telemetría, esto es, permiten al médico seguir el estado del paciente.

Un sistema de control de acceso debe cumplir una serie de propiedades. Ha de permitir un acceso sencillo y preciso a las partes autorizadas (personal médico), al tiempo que debería proteger la privacidad de dichos datos frente a terceros no autorizados. Debe permitir la identificación del dispositivo en cuestión (no queremos manipular el marcapasos equivocado, ¿no?). Debe permitir al personal autorizado configurar el sistema, al tiempo que lo impida a otros. Debe permitir su acceso a otros dispositivos autorizados (por ejemplo, un sistema de liberación de insulina debería poder acceder a los datos del medidor de glucosa para poder ajustar la dosis de forma automática). Y debe ser eficiente en términos de tamaño, tiempo y energía consumida.

Ya sabemos que un marcapasos es capaz de enviar al corazón señales de bajo voltaje para mantener el ritmo cardíaco. Un aparato similar, conocido como Desfibriladores Cardíacos Implantables (DCI) son, además, capaces de enviar un latigazo de alta tensión para "resetear" un corazón que late muy rápido. No es difícil imaginar que, si el DCI (o marcapasos) pueden transmitir señales, éstas pueden ser conducidas por vía inalámbrica hasta el despacho del médico, en cualquier parte del mundo y en tiempo real. Un DCI avanzado podría incluso almacenar una especia de memoria clínica rudimentaria, lo que puede incluir datos privados del paciente: su nombre, dirección, alergias, medicación, etc.

En lo que sigue emplearemos los términos "DCI" y "marcapasos" indistintamente, ya que en lo que nos afecta aquí sus diferencias no importan. Y basta por ahora de verborrea tipo House, y vamos a lo que nos interesa. Hemos dicho que los datos salen y entran, lo que significa que habrá que protegerlos. Parece que no es tan necesario, pero si los DCI y marcapasos intercambian datos como un RFID, son susceptibles de ser interrogados por cualquiera que pase por ahí. Podrían funcionar como dispositivos de rastreo, o ser aprovechados por agencias de publicidad, aseguradoras o vendedores sin escrúpulos. No creo que queramos ir filtrando ese tipo de datos tan altamente íntimos y confidenciales. A ver, pensemos qué soluciones podemos darle a esto...

¿Alguien ha dicho criptografía? Analicemos la situación. Veamos, por ejemplo, el problema de la confidencialidad de los datos de telemetría. Imaginemos un cifrado simétrico, rápido y eficiente, con dos claves: una en el marcapasos, otra en posesión del paciente. En condiciones normales, éste puede sacar su clave, insertarla en el aparato adecuado, y las lecturas saldrán en texto llano para ser utilizadas por el personal autorizado por el paciente. Ahora, sin embargo, tendremos que asegurarnos de que dicho aparato no haga una copia de la clave, problema no trivial pero que supondremos aquí resuelto. Ahora básicamente, tenemos resuelto un caso sencillo.

Pero ¿qué pasa si el paciente no está consciente? No es difícil imaginarlo: el personal de urgencias se pone en movimiento, intenta extraer las lecturas del DCI para intentar averiguar qué le pasa al paciente ... y un sistema criptográfico se lo impide. Hemos protegido los datos frente a personas no autorizadas, pero a costa de bloquear su acceso cuando más se los necesita.

Soluciones las hay, ya sea dar una tercera copia de la clave a un tercero de confianza, guardar la clave en una tarjeta o habilitar una puerta trasera para equipos de emergencia. Pero todo ello aumenta la inseguridad del sistema. Las claves han de ser transmitidas, el tercero de confianza puede no estar disponible en un momento crítico (!o no ser tan de confianza!), y las puertas traseras pueden ser mal utilizadas. Además de ello, requiere tiempo y calma, algo de lo que no suele andarse muy sobrado en situaciones de urgencia. En cuanto a guardar la clave en una tarjeta, podría facilitar las cosas a los usuarios de servicios de emergencia ("el paciente ha perdido el sentido, da igual, cogeremos su tarjeta"). Pero estamos igual que al principio. Si cualquiera puede coger la tarjeta y usarla, ¿dónde está la seguridad? Y si protegemos la tarjeta con una contraseña ¿cómo usarla si el paciente no está consciente?

De acuerdo, echemos mano de la criptografía de clave pública. Imaginemos la clave privada en el marcapasos, y la pública en ... bueno, en cualquier parte, que para eso es pública. Con una infraestructura de clave pública adecuada, cada hospital puede tener las claves públicas de todos los pacientes con marcapasos del país. O, si no queremos que todo el mundo sepa que tenemos un marcapasos, podemos guardarla en una tarjeta de memoria USB, escrita en un papel, en un colgante de ayuda médica, en un collar de plata con cristales de Swarowski, o como nos dé la gana. Con esa clave pública, el dispositivo de urgencias puede transmitirle al marcapasos una clave simétrica de sesión, y listo. La CCP podría asimismo ayudarnos con el problema de la integridad de datos, es decir, garantizarnos que no el DCI ni el equipo del hospital intercambian información errónea o alterada.

En principio, problema resuelto con final feliz. No es tan sencillo como suena aquí pero el hecho es que hay investigadores que han estudiado el uso de criptografía para resolver este problema (uno utilizaba el algoritmo RC5), particularmente en las áreas de autenticación e intercambio de claves.

Pero cuando yo le digo a mis alumnos "en principio", les enseño a traducirlo como "en la práctica, ni se os ocurra". La búsqueda de soluciones matemáticas teóricas no debe hacernos olvidar que, en el mundo real, usamos sistemas con limitaciones de tamaño, peso, energía, memoria, etc. La criptografía de clave pública es onerosa en términos de tiempo de computación (ya lo hemos hablado en el pasado), y por tanto, de energía, y un marcapasos tiene una capacidad de memoria y una energía limitadas. No se trata de un móvil con gran capacidad de cálculo, batería de tamaño respetable y un cargador con enchufes siempre a mano. Podemos aumentar la memoria del marcapasos merced a los avances de la técnica, pero no tanto la capacidad de la batería. Incluso en el caso de sistemas recargables mediante inducción, usar cripto significa disminuir la vida de la batería en particular, y del sistema en general. La tecnología RFID tampoco sirve, ya que un RFID obtiene la energía del lector que le interroga, y dicha energía es insuficiente para efectuar
operaciones de cifrado.

Lo peor de todo es que el problema debe ser resuelto. Imaginemos por un momento que, arrinconados en un callejón sin salida, nos damos por vencidos. Nada de criptografía. Nos resignaremos a un mundo en que los marcapasos filtran información médica sensible a cualquiera que los interrogue con un lector RFID. Escoger entre la privacidad y la propia vida es una elección clara: que mi corazón siga latiendo, y al diablo con la privacidad.

Pero no podemos tirar la toalla, porque hay en juego algo más que la privacidad del paciente. Está en juego su propia vida. Me explico. Como he dicho, algunos de los marcapasos más recientes son ajustables desde fuera, es decir, programables. Imaginemos ahora un usuario no autorizado !que programa el marcapasos para que se detenga! Una orden sencilla, y el DCI envía un chispazo de 700 voltios al corazón cuando éste no lo necesita. Si el presidente de Estados Unidos llevase uno de esos marcapasos, ya puede echar a correr Bruce Willis para salvarlo. Un supervillano de película podría lanzar una señal similar a toda la ciudad, alcanzando a millares de personas con marcapasos. ¿A que
ahora la cosa ha cambiado radicalmente?

Incluso ataques en apariencia inocuos pueden conllevar graves consecuencias. Cuando hablamos de "ataque criptoanalítico", no nos referimos a un asalto físico. Hablamos de tiempo de CPU, espacio de claves, emisión de mensajes, captación de paquetes de datos, ese tipo de cosas. Pero incluso interrogar a un sistema que tiene una batería limitada puede reducir la operatividad de ésta. Un millón de mensajes enviados y recibidos no significan nada para un router wifi, pero en un DCI es otra cosa. Cada vez que un paciente se suba al autobús, entre en un edificio con control de acceso o pase por un control aeroportuario, un lector RFID puede interrogar a su marcapasos. En cada respuesta, aunque sea para decir "no, pesado, que no soy yo", perdemos energía.

Existe una serie de comandos que pueden mantener un DCI en un estado de alerta. En dicho estado, una batería diseñada para durar dos años podría quedarse seca en dos semanas. Lo que es peor, mientras se encuentra en dicho estado no puede ser re-programado, lo que lo convierte en un ataque por Denegación de Servicio (DoS) doblemente peligroso.

 


 

 TEMAS DE ACTUALIDAD - A corazón abierto II

 

Es cierto que algunos de los problemas que acabo de anunciar son teóricos, poco prácticos y/o fácil de resolver. Pero existen, y crecerán en el futuro conforme aumente la sofisticación de los marcapasos y DCI. Como dije antes, cruzarse de brazos no es una opción. Por eso, los problemas asociados a la seguridad electrónica de los marcapasos han sido analizados en un par de artículos recientes. En uno de ellos, un equipo de investigadores de las universidades de Washington, Massachusetts-Amherst y de la Escuela Médica de Harvard (a partir de ahora, "el equipo"), han efectuado un ataque contra un DCI. Su artículo, titulado "Pacemakers and Implantable Cardiac Defibrillators: Sofware Radio Attacks and Zero-Power Defenses", cubre diversas áreas del problema. Por supuesto, no lo hicieron sobre un sujeto vivo, sino que colocaron un modelo DCI comercial en una bolsa llena con bacon y carne de ternera.

Para empezar, demostraron que es posible, usando osciloscopios y equipo técnico diverso, interrogar al DCI y, mediante ingeniería inversa, determinar cómo funciona. Algunos resultados son preocupantes. Por ejemplo, se supone que el DCI que utilizaron solamente transmite datos cuando se le acerca un imán exterior que cierra un interruptor magnético. Sin embargo, el equipo consiguió activar la transmisión telemétrica sin imán, utilizando solamente un comando de radiofrecuencia. El lector interesado en los detalles tiene el artículo en http://www.secure-medicine.org/icd-study/icd-study.pdf, que fue presentado en el IEEE Symposium on Security and Privacy. Por cierto, los amantes del software libre se alegrarán al saber que el equipo usó software GNU Radio.

El trabajo muestra que el DCI cotillea más que una portera. La información transmitida en claro incluía el nombre del paciente, su fecha de nacimiento, número identificador médico y su historia (clínica). Con los datos extraídos, fue un juego de niños deducir el nombre y número de teléfono del médico, fecha de implantación del DCI, modelo y número de serie. Las medidas de telemetría revelaban el ritmo cardíaco. Y menos mal que los autores no se lanzaron a un estudio a fondo de los protocolos de comunicación. Quién sabe que habría revelado un estudio completo mediante ingeniería inversa.

A continuación, se dedicaron a jugar a los ataques, escogiendo los que requerían poca complicación y violaban la confidencialidad o integridad de los datos. Los resultados asustan. No solamente consiguieron sonsacar al DCI los datos mencionados en el párrafo anterior, sino que llegaron a cambiar algunos de los datos que almacenaba, como el nombre del paciente o el reloj interno del DCI. También consiguieron apagar las terapias, lo que hace que no responda a eventos peligrosos, es decir, que no se active el "chispazo" de 700 voltios cuando lo necesite. Y a la inversa, consiguieron que el DCI indujese una fibrilación ventricular.

Todo esto no son elucubraciones teóricas. Son ataques reales, llevados a cabo por un equipo de investigadores que ni siquiera se lanzaron a fondo. Si esto lo pueden hacer personas bienintencionadas sin bajarse del autobús, ¿dónde está el límite para el Doctor Maligno de esta historia?

Los investigadores son conscientes de que las soluciones criptográficas, como hemos visto aquí, son onerosas en términos de energía, y pueden provocar problemas en casos de emergencia. Por ese motivo, ofrecen lo que ellos llaman "soluciones de potencia cero", que aumentan la seguridad del sistema sin requerir energía alguna del DCI.

La primera solución pasa por la detección. En sistema de "notificación de potencia cero" se basa en un sensor piezoeléctrico que, cuando recibe una señal de radiofrecuencia, emite un pitido de aviso (que puede sustituirse por una vibración). Dicho sensor está unido a un RFID especial, llamado WISP (Wireless Identification and Sensing Platform), que extrae energía de una señal de radiofrecuencia externa, de modo que no requiere energía del marcapasos o DCI (recuerden que usamos ambos términos indistintamente). Por supuesto, suena raro que el corazón de una persona comience a hacer "bip, bip", pero la idea puede refinarse. Es decir, la primera línea de defensa es la alerta.

La segunda consiste en autenticación, y aquí entra la criptografía, de modo que atentos todos, porque vamos a aprovechar para aprender (yo el primero). Los programadores comerciales (y con eso nos referimos no a personas, sino a dispositivos que interaccionan con el DCI) tendrán una clave maestra Km, que ha de guardarse en forma segura, a ser posible en hardware. Por su parte, cada DCI tiene un número de serie identificativo I, y una clave característica K. Dicha clave es una función de ambos factores, esto es, K=f(Km,I), donde f es una función criptográficamente fuerte y pseudoaleatoria (los autores proponen AES).

Así funciona el protocolo. El programador le envía al WISP (el dispositivo inalámbrico de comunicaciones del DCI) una petición de autenticación, una especie de "hola". Es habitual en los protocolos de autenticación intercambiar un número aleatorio para evitar que un atacante pueda usar una comunicación hecha anteriormente. Por eso, el DCI envía como respuesta su identificador I y un número aleatorio N. El programador calcula K=f(Km,I) para obtener la clave del DCI, y a continuación calcula una respuesta. Dicha respuesta R es el resultado de usar el algoritmo de cifra en bloque RC5 con K como clave y N como mensaje.

Es decir, el intercambio de datos vendría dado de esta forma:

        Programador                    DCI
        Hola ---------------------------->
        <---------------------------- (I,N)
        K=f(Km,I)
        R=RC5(K,N) ---------------------->

En este punto, el DCI calcula a su vez R'=RC5(K,N). Si el resultado obtenido es igual a la respuesta que ha recibido, esto es, si R'=R, entonces todo ha ido bien, porque eso significa que el programador tiene los valores correctos de K y de N. Puede parecer complicado, pero así cumple con su cometido de modo seguro. En primer lugar, no hemos intercambiado ningún dato sensible. Un atacante tan sólo podrá captar I (un número de identificación que no es secreto), N (un número aleatorio como cualquier otro) y R (resultado de cifrar N con una clave desconocida). Ni K ni Km han abandonado jamás sus contenedores.

Por otro lado, la respuesta del programador indica al DCI si es de fiar o no. Imaginemos por un momento que un interlocutor desconocido intenta ligar con el DCI, y, tras el intercambio de datos, R y R' no coinciden. Si eso sucede, puede ser por uno de los siguientes motivos.

- El interlocutor no conoce la clave maestra Km, lo que significa que no está metido en el secreto.
- La respuesta del interlocutor, R, está basada en un número aleatorio N' distinto de N, lo que indica que está reproduciendo un intercambio de datos que grabó en el pasado.
- La respuesta está basada en un identificador I' distinto de I, lo que significa que está intentando colar la conversación que tuvo con otro DCI en el pasado.

Es decir, sólo si R'=R podemos estar seguros de que el interlocutor conoce la clave secreta (Km) y ha respondido a la petición de identificación hecha en este momento y lugar. Todo lo que no sea eso está no autorizado. Incluso si el interlocutor es el programador autorizado, como no me de la respuesta que yo quiero oír, puerta.

Sin embargo, dije anteriormente que la criptografía no era la respuesta, ya que requiere energía y tiempo. Bien, no todo es blanco o negro. En este caso, no se utilizan más que algoritmos de cifrado simétrico, que son más rápidos que los de clave pública. Para simplificar, el equipo probó con un valor de N constante, lo que reduce la seguridad pero simplifica el proceso, y consiguieron ejecutar el algoritmo RC5 en el WISP, que recordemos toma la energía del exterior. Su conclusión es que sí puede usarse cripto para proteger al menos partes vitales de la información, aunque la pregunta de si pueda usarse para cifrar todo el flujo de datos permanece sin respuesta todavía. Tampoco resuelve el problema de la gestión de claves (cómo administrar y diseminar todas las Km, revocarlas si es preciso, etc) en entornos con grandes cantidades de claves revoloteando por ahí.

Finalmente, la tercera solución de potencia cero consiste en transmitir la clave criptográfica como hemos visto antes, pero utilizando un canal distinto. En lugar de echar mano de las ondas de radiofrecuencia, la clave se transmitiría por ondas acústicas o ultrasónicas. El aparato programador, situado en el exterior, tendría un micrófono que solamente podría captar la información en el caso de que estuviese físicamente en contacto con la piel del paciente; de otro modo, la señal sería demasiado débil para ser captada.

El decir, la triple solución de potencia cero consiste en a) avisar de ataques no autorizados, b) usar criptografía, al menos en forma simplificada, y c) decir la clave al exterior en voz muy baja.

Las soluciones para proteger marcapasos y otros dispositivos insertados en el cuerpo humano están en marcha, pero todavía falta mucha tela que cortar. Pero quiero tranquilizar a las personas que conozcan a alguien con marcapasos. Si bien los problemas que hemos mostrado aquí son factibles tanto de forma teórica como práctica, aún no se han dado en el mundo real. Requieren intención maliciosa, sofisticación técnica y acceso cercano al paciente. Los autores del artículo lo dejan bien claro, en una afirmación que yo comparto plenamente:

"Creemos firmemente que nada en nuestro informe debe disuadir a los pacientes que necesiten estos dispositivos si se los recomienda su médico. El desfibrilador cardíaco implantable es una técnica probada que salva vidas. Creemos que el riesgo a los pacientes es bajo y que los pacientes no deberían alarmarse."

Mientras tanto, los mejores expertos del ramo se unen en iniciativas como el Medical Device Security Center, un grupo interdisciplinario que ha realizado, entre otras cosas, el artículo anteriormente mencionado. Pueden recabar más información en su web de http://www.secure-medicine.org/. Arriba los corazones.

 



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