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
TEMAS DE ACTUALIDAD - Deconstruyendo SSL
TEMAS DE ACTUALIDAD - A corazón abierto I
TEMAS DE ACTUALIDAD - A corazón abierto II
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