Ús de Mifare Ultralight C amb RC522 a Arduino: 3 passos

2024 Autora: John Day | [email protected]. Última modificació: 2024-01-30 08:11

L’ús de la tecnologia RFID per identificar els titulars de la targeta o per autoritzar a fer alguna cosa (obrir una porta, etc.) és un enfocament força habitual. En cas d'aplicació de bricolatge, el mòdul RC522 s'utilitza àmpliament, ja que és bastant barat i existeix una gran quantitat de codi per a aquest mòdul.

En la majoria dels casos, l'UID de la targeta s'utilitza per "identificar" el titular de la targeta, i les targetes Mifare Classic s'utilitzen ja que són barates i sovint s'inclouen en comprar un mòdul RC522.

Però, com podríeu saber, el sistema Mifare Classic ha estat piratejat des de fa alguns anys i ja no es considera segur. Es pot superar el sistema de xifratge Crypto1 utilitzat per les targetes Classic i es poden tornar a escriure en les quals es poden reprogramar dades i un UID (cartes màgiques).

Per tant, per a qualsevol aplicació rellevant per a la seguretat, no es recomana l’ús de targetes Mifare Classic. El mateix s'aplica a la majoria de sistemes NTAG i Mifare Ultralight

Per tant, l'elecció és utilitzar un sistema professional o intentar utilitzar un sistema RFID més segur. Els sistemes disponibles són Mifare Ultralight C, Mifare DESFire i Mifare Plus. Com que hi ha molts sistemes professionals que utilitzen aquests sistemes més segurs, per a la comunitat de bricolatge pràcticament no hi ha solucions (hi ha una solució DESFire basada en Teensy, que es basa en el més costós tauler de ruptura PN523). A més, les targetes DESFire són bastant cares. Per tant, el repte era trobar una solució millor i més barata.

La solució presentada proporciona accés complet a les targetes Mifare Ultralight “C” barates mitjançant el mòdul de bricolatge xinès RC522. Basat en aquest codi, el Mifare Ultralight C segur es pot utilitzar en aplicacions de bricolatge.

Pas 1: requisits previs

Tot i que el RC522 està ben dissenyat, en la majoria dels casos està mal construït, ja que alguns components estan mal dimensionats. Això condueix a la mala reputació del mòdul perquè té una sensibilitat baixa i no s’identificaran tots els tipus de cartes. Especialment el Mifare Ultralight C no s’identificarà ni serà possible llegir les cartes.

El principal problema és l’especificació dels inductors L1 i L2. Tal com es descriu a https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Només substituint aquests inductors per altres adequats, p. FERROCORE CW1008-2200 de sobte, el RC522 mostra quin és el seu potencial real.

Per tant, abans de provar el codi donat, heu de substituir els inductors. Simplement no funcionarà amb els inductors preinstal·lats.

El fons de tot plegat és que les cartes Ultralight C tenen molta energia. Aquesta energia la proporciona el camp RF RC522. A causa del baix amperatge dels inductors, el camp d’energia no és prou potent per alimentar l’Ultralight C. Altres targetes com la Mifare Classic només necessiten menys potència i, per tant, funcionen bastant estables.

Pas 2: Com funciona?

Després de modificar el mòdul RC522, com podeu utilitzar el Mifare Ulralight C per a la vostra aplicació?

El truc és que Mifare Ultralight C admet una autenticació de contrasenya basada en el xifratge 3DES. En utilitzar aquesta contrasenya, el contingut de la targeta es pot fer "només de lectura" o completament invisible per a un usuari no autoritzat.

Per utilitzar aquesta protecció amb contrasenya, cal escriure la contrasenya a la targeta i protegir les pàgines. Un cop fet, podeu verificar la targeta a la vostra sol·licitud només demanant una autenticació basada en contrasenya o dades preparades addicionalment d'una àrea protegida. Només si això funciona correctament, sabeu que podeu confiar en l'ID proporcionat a la targeta.

Compte: sense l’autenticació basada en contrasenya encara no es pot confiar en una targeta Mifare Ultralight C, ja que també hi ha “cartes màgiques” que simulen l’Ultralight C.

Cada targeta independent de la tecnologia (si té la freqüència correcta) respondrà amb el seu UID quan estigui alimentat pel camp RF i sol·licitarà identificar-se. A més, proporcionen un valor SAK que proporciona informació mínima sobre el tipus de targeta present. Malauradament, tots els Mifare Ultralight i NTAG s’identifiquen com el tipus syme (SAK = 0x00), inclòs el Mifare Ultralight C. Per tant, quan es consulten cartes, almenys el valor SAK de 0x00 donarà una pista que pot haver-hi un Ultralight C al lector..

Per assegurar-vos que és un Ultralight C, es pot enviar a la targeta una sol·licitud d’autenticació xifrada. Si NO és una targeta Ultralight C, aquesta sol·licitud no s’entendrà i la resposta serà un NAK (not-acknolege).

Si es tracta d’una targeta Ulralight C, obtindreu una resposta de 8 bytes. Aquests 8 bytes són un número aleatori "B" (RndB) xifrat per la clau emmagatzemada a la targeta mitjançant el xifratge 3DES.

Aquest RndB xifrat s'ha de desxifrar amb la mateixa clau del programa. Aquest nombre aleatori es modifica lleugerament (girat per un byte → el byte 1 es mourà al byte 8 i tots els altres bytes s’enfonsaran un byte més baix, aleshores s’anomena RndB’). Aleshores, el programa genera un número aleatori "A" de 8 bytes (RndA) i adjunta aquest RndA al RndB modificat. Es torna a xifrar amb la clau i s'envia a la targeta.

La targeta desxifra el missatge i comprova si RndB’s’adapta al RndB generat anteriorment a la targeta. Si coincideixen, la targeta ja sap que el programa en sap la clau.

En aquest moment, el programa encara no sap si la targeta coneix la clau i, per tant, es pot confiar o no. Per aconseguir-ho, ara la targeta fa girar el RndA desxifrat en un byte, i després xifra aquests bytes amb la clau i els torna a enviar.

El programa desxifrarà la resposta de la targeta i comprovarà si el RndA original i el RndA respost coincideixen. NOMÉS LES dues entitats (programa i targeta) saben que comparteixen el coneixement de la mateixa clau.

Aquest procés només s’utilitza per autenticar-se. Totes les comunicacions posteriors sempre estan en un "text clar".

Tot i que hi ha cartes “màgiques Ultralight C” on es pot modificar l’UID, la clau en si mateixa no es pot obtenir de la targeta i el xifratge 3DES és bastant segur. La clau és una clau de 16 bytes, de manera que un enfocament de força bruta per obtenir la clau trigarà una mica.

Com s’ha dit, la comunicació prèvia a l’autenticació i després de l’autenticació sempre està en text clar (també no xifrat). Quan escriviu una clau nova a la targeta, es pot ensumar el contingut de la clau mitjançant l’equip adequat. Per tant, escriviu la clau només en un entorn segur i mantingueu la clau en secret.

En utilitzar la targeta Ultralight C.

La targeta Ultralight C té diverses funcions de seguretat integrades:

1. Memòria de programació única (OTP). En aquesta àrea es poden escriure bits, sense eliminar el bus.
2. Un comptador unidireccional de 16 bits. Aquest comptador només es pot incrementar quan s’accedeix.
3. Una protecció de "escriptura" o "lectura / escriptura" de pàgines a la memòria. Només si s’autentifica amb la clau, aquestes pàgines es poden llegir o modificar.
4. Una congelació / bloqueig de pàgines individuals per protegir-se de qualsevol modificació.

Ni l'ús d'OTP, el comptador de 16 bits ni l'ús del bit de bloqueig s'implementen en el codi donat, sinó que es poden implementar fàcilment basant-se en la informació proporcionada a https://www.nxp.com/docs/en/data- full / MF0ICU2.pd …

Com que la protecció per clau és essencial per utilitzar el Mifare Ultralight C, hi ha totes les funcions rellevants.

Totes les ordres s'utilitzen al monitor sèrie amb "només línia nova" i amb 115200 Baud

• "Auth 49454D4B41455242214E4143554F5946" sol·licitarà una autenticació amb la clau donada (en aquest cas, la clau estàndard Mifare Ultralight C)
• "Bolcar" volcarà el contingut de la targeta tant com sigui visible. En cas que les pàgines estiguin protegides per la clau, és possible que aquestes pàgines no siguin visibles fins a una autenticació prèvia amb la clau. A les dues primeres columnes s'indica si les pàgines estan bloquejades o l'accés està restringit.
• "NewKey 49454D4B41455242214E4143554F5946" escriurà una nova clau a la targeta. La clau s'escriu a les pàgines 44 a 47. Això només funcionarà si aquestes pàgines no estan bloquejades ni protegides sense una autenticació prèvia.
• "wchar 10 hello world" escriurà "hello world" a partir de la pàgina 10. Una vegada més, això només funciona a les pàgines que no estan bloquejades ni protegides sense una autenticació prèvia. s'ignoren els errors o les dades, ja que aquestes pàgines no són memòria de l'usuari.
• "Whex 045ACBF44688" escriurà els valors hexadecimals directament a la memòria, s'apliquen les condicions anteriors.
• "Protect 30" protegeix totes les pàgines de la pàgina 30 cap amunt. Depenent del permís, aquestes pàgines només es poden modificar o llegir després d’una autenticació prèvia amb clau. Si utilitzeu "protegir" amb valors superiors a 47, totes les pàgines seran "desprotegides" INCLOSA LA CLAU a les pàgines 44-47 (que només es poden modificar però no llegir). Per tal d’evitar l’alteració de la clau, la protecció hauria de començar com a mínim a la pàgina 44.
• "Setpbit 0" estableix el bit de protecció i decideix si les pàgines protegides només són de lectura ("setpbit 1") o no es poden llegir ni escriure ("setpbit 0") sense una autenticació prèvia amb clau.

No totes les ordres es poden utilitzar immediatament després de detectar la targeta. Un "bolcat" anterior a una altra ordre sempre ajuda.

Pas 3: important

1. El programa diferencia els tipus d’Ultralight mitjançant la lectura de les pàgines 43 i 44. Si la pàgina 43 es pot llegir i la pàgina 44 no, el més probable és que sigui un Ultralight C. PERUT, si protegiu la lectura / escriptura de la pàgina 43, la targeta ja no es reconeix com a Ultralight C (no té cap efecte en res) La identificació adequada del Ultralight s’ha de fer mitjançant l’autenticació amb clau (no ho he implementat per motius d’estabilitat).
2. Abans d'utilitzar les ordres "setpbit" i "protect" s'ha d'utilitzar l'ordre "dump", en cas contrari no es coneixerà l'estat de protecció de les pàgines.
3. Si protegiu les "primeres pàgines de la targeta" amb "llegir / escriure", ja no funcionarà amb aquest programa, ja que la primera pàgina es llegeix constantment per veure si encara hi ha una targeta present. Com que les dues primeres pàgines només es llegeixen de totes maneres (l’UID s’hi emmagatzema), no té cap sentit protegir-les.

Problemes d’estabilitat

Aquest codi utilitza la biblioteca RC522 "estàndard" per a Arduino i una biblioteca 3DES de https://github.com/Octoate/ArduinoDES. Tot i que la biblioteca RC522 s’utilitza amb força freqüència, la biblioteca 3DES no està tan estesa i s’ha d’instal·lar manualment.

El codi s'ha provat en un Arduino Uno. Però mentre l’escrivia, vaig trobar molts problemes estranys pel que fa a l’estabilitat. D’alguna manera, les meves habilitats de programació no són tan bones, una de les biblioteques utilitzades és inestable o barrejar les biblioteques no és una bona idea.

Tingueu-ho en compte quan utilitzeu el codi.

Canviar-lo o utilitzar-ne només algunes parts pot comportar un comportament estrany, com ara estavellar-se, imprimir coses estranyes o obtenir temps d’espera o NAK en llegir des de la targeta. Això pot passar a qualsevol lloc del codi (em va costar moltes hores de depuració). Si trobeu el / els motiu (s) d’això, doneu-me una pista.