Tras introducir el pasado viernes algunos aspectos teóricos relevantes de RFID, en esta segunda parte entraremos en cuestiones prácticas que nos darán resultados muy interesantes.

Comencemos profundizando un poco más en como Mifare realiza el proceso de autenticación. En primera instancia el lector le comunica a la tarjeta que quiere realizar una operación sobre un sector de datos determinado N. El tag o tarjeta en ese momento remite un número aleatorio Nc (Nonce del cliente) de 32 bits a modo de reto, para que sea cifrado con la clave privada compartida previamente. Como respuesta, el lector remite el reto cifrado y un número aleatorio Nr (Nonce del lector) para que el tag lo cifre con la clave privada, generando una trama de 64 bits. En última instancia la tarjeta le envía al lector su reto cifrado. En este momento ambos tienen la certeza de que los dispositivos son legítimos. Destacar que los dos últimos intercambios se realizan ya de forma cifrada, permaneciendo en claro tan solo el envío de la petición de lectura y Nc. La figura de la izquerda ilustra el proceso de handshake.

Este proceso de saludo a 4 bandas es importante ya que de él extraeremos la información necesaria para inferir la clave privada del sector.

Procedamos ahora a realizar una prueba de concepto que nos permitirá, a partir de la captura de la información anterior, inferir la clave privada. Pero, ¿cómo podemos capturar una comunicación real entre un tag y un lector? Aquí es donde juega un papel importante el PROXMARK III. Este dispositivo desarrollado por Jonathan Westhues permite realizar sniffing de varias tecnologías RFID desde baja frecuencia (LF 125 Khz) a alta frecuencia HF (13.56 Mhz) y entre ellas la que nos interesa ISO14443 tipo A sobre la que se basa Mifare. En un principio el PROXMARK III supondría el Hardware sobre el cual se pueden implementar diversas capas físicas y de enlace, de diferentes protocolos, simplemente programando sus integrados con la especificación que se requiera.

Muy bien, pues ya tenemos el dispositivo que nos permitirá capturar el handshake inicial entre la tarjeta y el lector, ahora tan solo nos falta un lector Mifare y una tarjeta. Para el lector, en este caso se ha optado por un Omnikey 5321 que viene con un software de ejemplo que permite la interacción con tags Mifare sin la necesidad de utilizar su API y programarse uno mismo el código. Para la tarjeta se ha utilizado una Mifare classic 4k. La captura de la derecha muestra la maqueta utilizada.

Como se puede ver la antena es casera, realizada a partir de un cable USB y no muy “profesional” pero para lo que nos acontece sobra, consiguiendo incluso sobre los 12500 mV en el test Tune (test que implementado en el firmware del PROXMARK III).

Colocando el sniffer entre la tarjeta y el lector podríamos proceder a realizar una lectura del sector 4, obteniendo la siguiente traza de bytes (véase Gerard de Koning Gans, Jaap-Henk Hoepman, Flavio D. Garcia. A practical Attack on the MIFARE classic. Radboud University Nijmegen 2008):

Es conveniente comentar ciertos aspectos de la captura:

• En primer lugar ETU corresponde con Elementary Time Units, y define el tiempo entre mensajes, donde 1 ETU corresponde con un cuarto del período de bit, que es igual a 1,18 microsegundos.
• SEQ en este caso correspondería con el número de mensaje.
• La trama “2a 69 8d 43 8d” identifica la tarjeta Mifare dentro del rango del lector, este identificador es pregrabado en el sector 0 del tag y no es modificable.
• El byte “60” de la secuencia “07” indicaría a la tarjeta que se pretende trabajar y por tanto autenticar, en un sector determinado, en este caso el sector 01 donde esta albergado el bloque de datos 04 (siguiente byte al “60”) y utilizando para ello la clave A. Si nos encontráramos con un valor “61” se trataría de un intento de autenticación utilizando la clave B del sector.
• El resto de tramas que implican el proceso de autenticación ya han sido comentadas anteriormente (Nc, Nr, Rc, Rr).

Con la información anterior capturada procederemos a inferir la clave privada del sector mediante la aplicación CRAPTO1 de desarrollo anónimo (lógico dado los problemas que tuvo la universidad de Radboud con Philips por su investigación).

Configuramos crapto1 con los parámetros anteriores:

uint32_t uid             = 0x2a698b43;
uint32_t tag_challenge   = 0x3bae032d;
uint32_t nr_enc          = 0xc494a1d2;
uint32_t reader_response = 0x6e968642;
uint32_t tag_response    = 0x8466059e;

Pasamos a compilar la aplicación:

roberto@hacklab:~/Mifare/crapto-v1.1$ gcc -o post post.c crapto1.c crypto1.c

Y obtenemos por fin la ansiada clave :

roberto@hacklab:~/Mifare/crapto-v1.1$ ./post
nt': 7fcf34c3
nt'': 869dbbd5
ks2: 1159b281
ks3: 02fbbe4b
Found Key: [85 cc f9 ff ff ff]

Con esta clave privada ya podemos pasar a leer/modificar el contenido de los 4 bloques de datos que componen el sector 01, podríamos por ejemplo, cambiar esta clave privada escribiendo en el bloque de datos trailer o incrementar el valor de nuestro monedero electrónico. Cuidado al realizar esta primera operación, ya que podríamos modificar el tipo de acceso (3 bytes de Acces Conditions) y dejar el sector (todos los bloques de datos que lo componen!) inservible. Para más información sobre estos 3 bytes ojear ISO14443-A, Identification cards – Contactless integrated circuit(s) cards – Proximity cards (2006). Lo más habitual es encontrarse con el resto de sectores protegidos con la misma clave privada, con lo que se podría proceder a realizar un clonado completo de la tarjeta (salvo el UID, auque normalmente no lo comprueban las aplicaciones).

En resumen hemos visto como es posible comprometer la seguridad de este tipo de tecnologías RFID. Como apunte final, alarma la cantidad de empresas y entidades a nivel mundial que utilizan Mifare Classic como sistema de ticketing, monedero electrónico o control de acceso físico. No voy a revelar que organismos lo hacen, pero más de los que os imagináis.

Happy RFIDing!

(+4 rating, 4 votes)

 Loading ...