Tango Attack: Cómo atacar (y proteger) dispositivos IoT RFID

La tecnología RFID o Radio Frecuency Identification es una tecnología Wireless compuesta por dos componentes: Tag y Reader. El Reader es un dispositivo que tiene una o más antenas y emite señales de radio recibidas por el RFID Tag. El Tag es un objeto pequeño incorporado a un producto, animal o persona con el objetivo de identificarse ante el Reader. Aunque supongo que lo sabréis, vuestro pasaporte tiene un tag RFID… pero no juguéis y lo toquéis mucho o tendréis problemas con la ley.

Figura 1: Tango Attack: Cómo atacar (y proteger) dispositivos IoT RFID

La gran diferencia entre RFID y los típicos códigos de barras es que los primeros son identificadores únicos, además de poder identificarse a mayor distancia y sin visibilidad completa. Por el contrario, estos suelen ser más caros.

Figura 2: Tag y Reader en tecnología RFID, y ordenador con la base de datos.

En cuanto a tipos de Tag, existen de tres tipos:

• Pasivos: Con una distancia útil de 3.3m, son los más baratos.

• Semi-pasivos: Hasta 10m útiles de comunicación, se utilizan para seguimiento o "tracking" en el mundo del comercio.

• Activos: Alcanzan más de 10m útiles, se utilizan para hacer seguimiento o "tracking" de objetos de gran valor o personas.

Este tipo de sistemas tiene distintos problemas de seguridad en caso de no ser configurados de forma correcta, pero nos fijaremos únicamente en los siguientes supuestos:

• Confidencialidad: En caso de no estar cifrados, el atacante podría con un reader RFID capturar el valor del ID al vuelo, sabiendo qué elemento es el capturado en caso de tener acceso a la base de datos.

• Privacidad: En caso de no tener aleatoriedad en la comunicación, el atacante podría localizar el objeto en todo momento, ya que la comunicación se repetiría.

• Autenticación: En el supuesto anterior, el atacante podría reutilizar la llamada del RFID anterior para hacer que el tag se identifique las veces que desee, como en el ejemplo que nos contaba nuestro compañero Sergio Sancho con la clonación de alarmas RFID.

• Integridad: En caso de que el tag no tenga protocolos de chequeo de la información recibida, el atacante podría realizar un Man in the Middle y modificar al vuelo la información.

En estos sistemas existe un balance coste-beneficio asociado a los protocolos de criptografía a utilizar, igual que pasa en los dispositivos IoT: no hace falta que se proteja de la misma forma tu pasaporte que la marca de medicamentos de Ibuprofeno. ¿O sí, ya que puede ser información sensible? Esta pregunta es la que deben responder los fabricantes.

Figura 3: Libro de Cifrado de las comunicaciones digitales:
de la cifra clásica a RSA 2ª Edición de 0xWord

Ahora os hablaré de un protocolo llamado David-Prasad, y aunque no se utilice en los dispositivos anteriormente comentados, nos hará entender la problemática del asunto. En este repositorio que hicimos con María Teresa Nieto, podéis ver la implementación de todo lo que voy a explicar. 

Protocolo David-Prasad

En este protocolo, el Tag y el Reader se intercambian 2 bloques de información (Reader->Tag, Tag->Reader), enviando el Reader los mensajes A, B y D y el Tag los mensajes E y F. Pero primero veamos un esquema de qué información tiene cada uno, que se ha transmitido previamente por un canal seguro una única vez.

Figura 4: Esquema Reader-Tag en protocolo David-Prasad

Como observamos, tanto el Tag como el Reader tienen K1 y K2 (dos claves de cifrado simétricas y aleatorias) y PID2, un pseudónimo del identificador del Tag que permite a ambos saber quién es a quien se quiere identificar, que se inicializa de forma aleatoria.

Figura 5: Generación de A, B y D en el Reader

Entonces el Reader genera dos números aleatorios n1 y n2, y construye los mensajes A, B y D tal y como se explica en la Figura 5 y los envía al Tag como se ven en la imagen siguiente.

Figura 6: Esquema Reader-Tag en protocolo David-Prasad, step A,B,D

El Tag recibe los mensajes y calcula los valores n1 y n2, que no los conocía y han sido generados en esa ejecución por al Reader. Como el XOR es una operación reversible, y dado que el Tag conoce PID2, K1 y K2, puede saber n1 y n2 con las siguientes operaciones:

Figura 7: Fórmulas de recuperación de n1 y n2

Además, debe comprobar el mensaje D para ver que nadie ha modificado ninguno de los bits de la transmisión de información:

Figura 8: Formula de comprobación de D

Ahora es cuando el Tag debe enviar, también cifrado, su ID. Esto lo realizará con dos mensajes, E y F siguiendo el esquema de comunicación que hemos descrito.

Figura 9: Fórmulas de los mensajes E y F

Figura 11: Esquema Reader-Tag en protocolo David-Prasad, step E,F

A partir del intercambio de estos mensajes, el ID del Tag ya puede calcularse con la siguiente fórmula descrita aquí:

Figura 12: Fórmula de recuperación de ID

Además, se chequea que n1 y n2 hayan sido transmitidos correctamente con el mensaje F. Por último, se recalculan los pseudónimos para que los siguientes mensajes no tengan la misma información:

Figura 13: Cálculo de pseudónimos

Hasta aquí, ¡guay! El protocolo parece seguro ya que tiene aleatoriedad y cifrado, además de utilizar operaciones no lineales y no tiene pinta de ser fácil de romper… ¿o sí? Hace ya un tiempo unos investigadores fueron capaces de romper el protocolo a partir de la estadística, utilizando un ataque llamado Tango Attack. Las matemáticas, como siempre, rompiendo criptografía. Un clásico. 

Ataque Tango Attack

Esta investigación se basaba en la escucha de distintas iteraciones para romper el protocolo y encontrar los valores de K1, K2 e ID. Es decir, si Charlie escucha las conversaciones (mensajes A, B, D, E y F) durante un tiempo, éste será capaz de encontrar los secretos compartidos y suplantar al Identificador, por ejemplo. Veamos como:

• Los bits de los mensajes no son completamente aleatorios, ya que las operaciones AND, por ejemplo, hacen que estos estén sesgados a ciertos valores.

• Aunque n1 y n2 sean distintos en iteraciones consecutivas, podemos explotar la periodicidad de algunos valores.

• Los investigadores estudiaron qué combinaciones XOR entre A, B, D, E y F daban mejores estimaciones de K1, K2 e ID a partir de la distancia Hamming media entre el estimador y el objetivo.

Para apoyar mi explicación con imágenes, utilizaré los apuntes del investigador y profesor de la UC3M Pedro Peris, experto en Criptografía LightWeight. Si realizamos distintas simulaciones con K1, K2 e ID diferentes, y calculamos la distancia de Hamming con las estimaciones, encontraremos una tabla parecida a:

Figura 14: Tabla Distancia de Hamming por algunas de las posibles combinaciones de operaciones XOR entre A, B, D, E y F. L es el estimador y en las distintas columnas está la media de la distancia y su desviación típica.

En la tabla anterior podemos encontrar algunas combinaciones interesantes que nos pueden servir para estimar K1, por ejemplo. Estas simulaciones se han realizado con K1, K2 e ID enteros de N bits. Utilizando el mensaje D tenemos, por ejemplo, una distancia de Hamming media de 34 bits. Eso quiere decir que si suponemos que D es K1, podemos saber que, aproximadamente, 34 bits los tendremos erróneos de los 90, mejorando en 11 bits si hiciéramos esta suposición con un número aleatorio de 90 bits.

Figura 15: Estimaciones para secretos K1, K2 e ID

Cogiendo las estimaciones que más número de bits realizamos bien, es decir, las que tienen menor distancia de Hamming, y negando las estimaciones que más número de bits realizamos mal, o lo que es lo mismo, los que mayor distancia de Hamming, podemos encontrar esas combinaciones que mayor número de bits nos hace conocer, como vemos en la Figura 15.

Figura 16: Para el caso ID y mensajes A, B, D, E y F de 8 bits, podemos estimar correctamente ID con sólo dos iteraciones

¿Y cómo escogeremos el secreto estimado en función de nuestras aproximaciones? Con la moda por cada una de las posiciones de bit. Si entre nuestras estimaciones, para la posición X, se repite más el valor 1, supondremos que el secreto en la posición X será un 1, y viceversa. Veamos el ejemplo de la Figura 16.

Figura 17: Número de iteraciones (eje x) vs Distancia de Hamming entre estimación del ID y el propio ID (eje Y) con 32 bits

Para una clave de 8 bits, con únicamente 2 sesiones (se intercambian Tag y Reader dos pares de A, B, D, E y F) somos capaces de romper el protocolo. Para el caso de 32 bits, el que hicimos en nuestra implementación en el repositorio, podemos ver que aunque se necesiten más, podemos seguir rompiéndolo (Branch master).

Figura 18: Una simulación de los valores K1, K2 e ID y sus respectivas estimaciones con 32 bits.

Vosotros, lectores, podríais pensar que el caso de que se hagan tantas lecturas (en nuestro caso anterior con 20/25 es suficiente) es algo inviable. Pero no es así. Supongamos una situación como esta: la tarjeta de tu universidad está equipada con un dispositivo RFID. Toda la Universidad está diseñada para que en cada una de las salas haya distintos lectores RFID para poder hacer seguimiento de tarjetas en caso de que exista algún caso de Covid-19. 

La idea sería que si has estado en la misma sala que Paco, y Paco da positivo, tanto tú como él tenéis que hacer cuarentena. Teniendo en cuenta que se realiza, como mínimo, una lectura por cada entrada a una sala de la universidad, que entras y/o sales del aula 2 veces por clase y tienes 5 clases por día… Con que el atacante esté en la sala 2 días, ya podría tener 20 mensajes tuyos y poder suplantar tu identidad.

Protección contra el Tango Attack

¿Pero, si no me puedo fiar del cifrado ni de la frescura del protocolo, cómo podemos defendernos en esta situación? En nuestro repositorio realizamos una defensa muy sencilla que evita cualquier estudio estadístico de los mensajes, y está basado en otra operación poco costosa de realizar, como es la rotación. El protocolo David-Prasad es ultra-ligero, por lo que cualquier tipo de operación sumamente compleja para engañar a posibles adversarios haría imposible de implementarlo en nuestro dispositivo.

Si habéis leído detenidamente (que espero que sí), os habréis fijado que para que se realice este tipo de ataque se necesita estimar los mensajes por posición de bit. Si sincronizamos Tag y Reader para que sepan que se están rotando los mensajes N posiciones, y Charlie no sabe cuánto se están rotando en ese momento, seremos capaces de intercambiar mensajes de la misma forma sin ser susceptibles a este ataque.

Únicamente rotando el mensaje E por el módulo L de PID2 (que va cambiando en cada iteración) éramos capaces de defendernos de este ataque estadístico para el ID. Imaginemos que PID2 = 2 y L = 8 en esta iteración, y el mensaje E es 00101100. 

• Tag genera E: 00101100

• Tag calcula cuanto tiene que rotarlo: PID2 % L = 2

• Rota E a derechas (2 posiciones) y lo envía: 00001011 (este mensaje es capturado por Charlie)

• Reader recibe E rotado y lo rota a izquierdas (PID2 % L = 2 posiciones): 00101100

Charlie conoce los bits del mensaje rotado de E de esa iteración, pero como E irá cambiando cada sesión y también PID2, Charlie no podrá averiguar el mensaje original. PID2 es un secreto compartido por Tag y Reader en cada una de las sesiones, por lo que podríamos seguir enviando mensajes sin problema. Si aplicamos esta defensa y simulamos 100 iteraciones obtenemos las siguientes estimaciones con 32 bits:

Figura 19: 100 sesiones con defensa de Rotación de E

Como vemos, aunque la rotación de E no permita que el adversario conozca el valor de K1 y K2, sí que evitamos que robe el ID aún y escuchando 100 sesiones. Si hiciéramos lo mismo para los 5 mensajes intercambiados, algo que a nivel de programación no es complejo, podríamos ser capaces de evitar cualquier tipo de estimación estadística parecida tanto para ID, K1 y K2.

Reflexiones finales

Los dispositivos IoT y la tecnología RFID han supuesto un cambio a todos los niveles en nuestro día a día. La criptografía, uno de los campos, a mi parecer, más apasionantes de la ciberseguridad, tiene una gran problemática como es el balance seguridad-coste. Especialmente en los casos más mundanos, como sería el tracking de personas en espacios cerrados, deberíamos tener cuidado con cómo implementamos la seguridad de los mensajes intercambiados.

Saludos,

Autor: Bruno Ibáñez, Investigador de Ciberseguridad e IA en Ideas Locas

Contactar con Bruno Ibáñez