Usando Mifare Ultralight C con RC522 en Arduino: 3 pasos

2024 Autor: John Day | [email protected]. Última modificación: 2024-01-30 08:40

El uso de la tecnología RFID para identificar a los titulares de tarjetas o para autorizar hacer algo (abrir una puerta, etc.) es un enfoque bastante común. En el caso de la aplicación de bricolaje, el módulo RC522 se usa ampliamente, ya que es bastante barato y existe una gran cantidad de código para este módulo.

En la mayoría de los casos, el UID de la tarjeta se usa para "identificar" al titular de la tarjeta, y las tarjetas Mifare Classic se usan ya que son baratas y a menudo se incluyen al comprar un módulo RC522.

Pero como ya sabrás, el sistema Mifare Classic ha sido pirateado durante algunos años y ya no se considera seguro. El sistema de cifrado Crypto1 utilizado por las tarjetas Classic se puede superar y son tarjetas regrabables donde se pueden reprogramar datos y UID (tarjetas mágicas).

Por lo tanto, para cualquier aplicación relevante para la seguridad, no se recomienda el uso de tarjetas Mifare Classic. Lo mismo se aplica a (la mayoría) de los sistemas ultraligeros NTAG y Mifare.

Por tanto, la elección es utilizar un sistema profesional o intentar utilizar un sistema RFID más seguro. Los sistemas disponibles son Mifare Ultralight C, Mifare DESFire y Mifare Plus. Como hay muchos sistemas profesionales que utilizan estos sistemas más seguros, para la comunidad de bricolaje prácticamente no hay soluciones (hay una solución DESFire basada en Teensy, que se basa en la placa de conexión PN523 más cara). Además, las tarjetas DESFire son bastante caras. Por tanto, el desafío consistía en encontrar una solución mejor y más económica.

La solución presentada proporciona acceso completo a las tarjetas Mifare Ultralight “C” económicas utilizando el módulo de bricolaje chino RC522 barato. Según este código, el seguro Mifare Ultralight C se puede utilizar en aplicaciones de bricolaje.

Paso 1: condiciones previas

Aunque el RC522 está bien diseñado, en la mayoría de los casos está mal construido ya que algunos componentes están mal dimensionados. Esto lleva a la mala reputación del módulo que tiene baja sensibilidad y no se identificarán todos los tipos de tarjetas. Especialmente el Mifare Ultralight C no será identificado ni será posible leer las tarjetas.

El principal problema es la especificación de los inductores L1 y L2. Como se describe en https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Simplemente reemplazando estos inductores por los apropiados, p. Ej. FERROCORE CW1008-2200 de repente el RC522 muestra cuál es su potencial real.

Entonces, antes de probar el código dado, DEBE REEMPLAZAR los inductores. ¡Simplemente no funcionará con los inductores preinstalados!

El trasfondo de todo esto es que las tarjetas Ultralight C consumen mucha energía. Esta energía es proporcionada por el campo de RF RC522. Debido al bajo amperaje de los inductores, el campo de energía no es lo suficientemente potente para alimentar el Ultralight C. Otras tarjetas como la Mifare Classic solo necesitan menos energía y, por lo tanto, funcionan de manera bastante estable.

Paso 2: ¿Cómo funciona?

Entonces, después de modificar el módulo RC522, ¿cómo puede usar Mifare Ulralight C para su aplicación?

El truco es que Mifare Ultralight C admite una autenticación de contraseña basada en el cifrado 3DES. Al usar esta contraseña, el contenido de la tarjeta se puede convertir en "solo lectura" o completamente invisible para un usuario no autorizado.

Para utilizar esta protección con contraseña, la contraseña debe escribirse en la tarjeta y las páginas deben estar protegidas. Una vez hecho esto, puede verificar la tarjeta en su aplicación simplemente solicitando una autenticación basada en contraseña o datos adicionales listos de un área protegida. Solo si tiene éxito, sabrá que puede confiar en el UID proporcionado en la tarjeta.

Tenga cuidado: sin la autenticación basada en contraseña, todavía no puede confiar en una tarjeta Mifare Ultralight C, ya que también hay "tarjetas mágicas" que simulan la Ultralight C.

Cada tarjeta independiente de la tecnología (si está en la frecuencia correcta) responderá con su UID cuando esté alimentada por el campo de RF y solicitará identificarse. Además, proporcionan un valor SAK que proporciona información mínima sobre el tipo de tarjeta que está presente. Desafortunadamente, todos los Mifare Ultralight y NTAG se identifican como del tipo syme (SAK = 0x00), incluido el Mifare Ultralight C. Por lo tanto, cuando se sondean las tarjetas, al menos el valor SAK de 0x00 dará una pista de que podría haber un Ultralight C en el lector..

Para asegurarse de que sea un Ultralight C, se puede enviar una solicitud de autenticación encriptada a la tarjeta. Si esta NO es una tarjeta Ultralight C, esta solicitud no se entenderá y la respuesta será un NAK (not-acknolege).

Si se trata de una tarjeta Ulralight C, obtendrá una respuesta de 8 bytes. Estos 8 bytes son un número aleatorio "B" (RndB) cifrado por la clave almacenada en la tarjeta utilizando el cifrado 3DES.

Este RndB cifrado debe descifrarse utilizando la misma clave en el programa. Luego, este número aleatorio se modifica ligeramente (se gira un byte → el byte 1 se moverá al byte 8 y todos los demás bytes se empujarán un byte más abajo, luego se llamarán RndB '). A continuación, el programa genera un número aleatorio de 8 bytes "A" en sí mismo (RndA) y adjunta este RndA al RndB’modificado. Esto se vuelve a cifrar con la clave y se envía a la tarjeta.

La tarjeta descifra el mensaje y comprueba si RndB’se ajusta al RndB generado previamente en la tarjeta. Si coinciden, la tarjeta ahora sabe que el programa conoce la clave.

En este punto, el programa aún no sabe si la tarjeta conoce la clave y, por lo tanto, puede ser confiable o no. Para lograr esto, la tarjeta ahora rota el RndA descifrado en un byte, luego cifra estos bytes usando la clave y los envía de vuelta.

A continuación, el programa descifrará la respuesta de la tarjeta y comprobará si el RndA original y el RndA respondido coinciden. SÓLO ENTONCES ambas entidades (programa y tarjeta) saben que comparten el conocimiento de la misma clave.

Este proceso solo se utiliza para autenticarse. Todas las demás comunicaciones se realizan siempre en "texto claro".

Aunque hay tarjetas “Magic Ultralight C” en las que se puede modificar el UID, la clave en sí no se puede obtener de la tarjeta y el cifrado 3DES es bastante seguro. La clave es una clave de 16 bytes, por lo que un enfoque de fuerza bruta para obtener la clave llevará algún tiempo.

Como se indicó, la comunicación antes de la autenticación y después de la autenticación siempre se realiza en texto sin cifrar (también conocido como no cifrado). Al escribir una nueva clave en la tarjeta, el contenido de la clave se puede rastrear utilizando el equipo adecuado. Por lo tanto, escriba la clave solo en un entorno seguro y mantenga la clave en secreto.

Al usar la tarjeta Ultralight C

La tarjeta Ultralight C tiene varias funciones de seguridad integradas:

1. Memoria de programación única (OTP). En esta área se pueden escribir bits, bus no borrar.
2. Contador unidireccional de 16 bits. Este contador solo puede incrementarse cuando se accede.
3. Una protección de "escritura" o "lectura / escritura" de las páginas en la memoria. Solo si se autentica con la clave, estas páginas se pueden leer o modificar.
4. Un congelamiento / bloqueo de páginas individuales para proteger contra cualquier modificación.

Ni el uso de OTP, el contador de 16 bits ni el uso del bit de bloqueo se implementan en el código dado, pero se pueden implementar fácilmente en base a la información proporcionada en https://www.nxp.com/docs/en/data- hoja / MF0ICU2.pd…

Como la protección por llave es fundamental para utilizar el Mifare Ultralight C, todas las funciones relevantes están presentes.

Todos los comandos se utilizan en el monitor serial con "solo nueva línea" y con 115200 baudios

• “Auth 49454D4B41455242214E4143554F5946” solicitará una autenticación con la clave dada (en este caso, la clave estándar Mifare Ultralight C)
• "Dump" volcará el contenido de la tarjeta hasta donde sean visibles. En caso de que las páginas estén protegidas por la clave, es posible que estas páginas no sean visibles hasta una autenticación previa con la clave. En las dos primeras columnas se indica si las páginas están bloqueadas o el acceso restringido.
• “NewKey 49454D4B41455242214E4143554F5946” escribirá una nueva clave en la tarjeta. La clave está escrita en las páginas 44 a 47. Esto solo funcionará si estas páginas no están bloqueadas ni protegidas sin una autenticación previa.
• "wchar 10 hola mundo" escribirá "hola mundo" a partir de la página 10. Una vez más, esto solo funciona si las páginas no están bloqueadas ni protegidas sin una autenticación previa. Cuando intente escribir arriba de la página 39 o debajo de la página 4, aparecerá un mensaje El error o los datos se ignoran ya que estas páginas no son la memoria del usuario.
• "Whex 045ACBF44688" escribirá valores hexadecimales directamente en la memoria, se aplican las condiciones anteriores.
• “Proteger 30” protege todas las páginas desde la página 30 en adelante. Dependiendo del permiso, estas páginas solo se pueden modificar o leer después de una autenticación previa con clave. El uso de “proteger” con valores superiores a 47 establecerá todas las páginas como “desprotegidas” INCLUYENDO LA LLAVE en las páginas 44-47 (que solo se puede modificar pero no leer). Para evitar alterar la clave, la protección debe comenzar al menos en la página 44.
• “Setpbit 0” establece el bit de protección y decide si las páginas protegidas son de solo lectura (“setpbit 1”) o no se pueden leer ni escribir (“setpbit 0”) sin una autenticación previa con clave.

No todos los comandos se pueden usar inmediatamente después de que se detecta la tarjeta. Un "volcado" previamente a otro comando siempre ayuda.

Paso 3: importante

1. El programa diferencia entre los tipos Ultraligeros leyendo las páginas 43 y 44. Si la página 43 es legible y la página 44 no, lo más probable es que sea una Ultraligera C. PERO, si protege la página 43 contra lectura / escritura, la tarjeta ya no se reconoce como Ultralight C (no tiene ningún efecto en nada) La identificación adecuada del Ultralight debe realizarse mediante la autenticación con clave (no lo implementé por razones de estabilidad).
2. Antes de usar los comandos “setpbit” y “protect” se debe usar el comando “dump”, de lo contrario no se conocerá el estado de protección de las páginas.
3. Si protege las primeras páginas de su tarjeta de “lectura / escritura”, no funcionará más con este programa, ya que la primera página se lee constantemente para ver si todavía hay una tarjeta presente. Como las dos primeras páginas se leen de todos modos (el UID se almacena allí), no tiene sentido protegerlas.

Problemas de estabilidad

Este código utiliza la biblioteca RC522 "estándar" para Arduino y una biblioteca 3DES de https://github.com/Octoate/ArduinoDES. Mientras que la biblioteca RC522 se usa con bastante frecuencia, la biblioteca 3DES parece no estar tan extendida y debe instalarse manualmente.

El código ha sido probado en un Arduino Uno. Pero mientras lo escribía, encontré muchos problemas extraños con respecto a la estabilidad. De alguna manera, mis habilidades de programación no son tan buenas, una de las bibliotecas utilizadas es inestable o mezclar las bibliotecas no es una buena idea.

¡Tenga esto en cuenta cuando utilice el código!

Cambiarlo o usar solo partes de él puede provocar un comportamiento extraño como fallar, imprimir cosas extrañas o obtener tiempos de espera o NAK al leer de la tarjeta. Esto puede suceder en cualquier lugar del código (me costó muchas horas de depuración). Si encuentra la (s) razón (es) de esto, por favor déme una pista.