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